Tag Archives: AWS Security Profile

AWS Security Profiles: Mark Ryland, Director, Office of the CISO

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-mark-ryland-director-office-of-the-ciso/

Author photo

Mark Ryland at the AWS Summit Berlin keynote

In the weeks leading up to re:Inforce, 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’s your current role?

I’ve been at AWS for almost eight years. For the first six and a half years, I built the Solutions Architecture and Professional Services teams for AWS’s worldwide public sector sales organization—from five people when I joined, to many hundreds some years later. It was an amazing ride to build such a great team of cloud technology experts.

About a year and a half ago, I transitioned to the AWS Security team. On the Security team, I run a much smaller team called the Office of the CISO. We help manage interaction between our customers and the leadership team for AWS Security. In addition, we have a number of internal projects that we work on to improve interaction and information flow between the Security team and various AWS service teams, and between the AWS security team and the Amazon.com security team.

Why is your team called “the Office of the CISO”?

A lot of people want to talk to Steve Schmidt, our Chief Information Security Officer (CISO) at AWS. If you want to talk to him, it’s very likely that you’re going to talk to me or to my team as a part of that process. There’s only one of him, and there are a few of us. We help Steve scale a bit, and help more customers have direct interaction with senior leadership in AWS Security.

We also provide guidance and leadership to the broader AWS security community, especially to the customer-facing side of AWS. For example, we’re leaders of the Security and Compliance Technical Field Community (TFC) for AWS. The Security TFC is made up of subject matter experts in solutions architecture, professional services, technical account management, and other technical disciplines. We help them to understand and communicate effectively with customers about important security and compliance topics, and to gather customer requirements and funnel them to the right places.

What’s your favorite part of your job?

I love communicating about technology — first diving deep to figure it out for myself, and then explaining it to others. And I love interacting with our customers, both to explain our platform and what we do, and, equally important, to get their feedback. We constantly get great input and great ideas from customers, and we try to leverage that feedback into continuous improvement of our products and services.

What does cloud security mean to you, personally? Why is it a topic you’re passionate about?

I remember being at a private conference on cybersecurity. It was government-oriented, and organized by a Washington DC-based think-tank. A number of senior government officials were talking about challenges in cybersecurity. In the middle of an intense discussion about the big challenges facing the industry, a former, very senior official in the U.S. Government intelligence community said (using a golfing colloquialism), “The great thing about the cloud is that it’s a Mulligan; it’s a do-over. When we make the cloud transition, we can finally do the right things when it comes to cybersecurity.

There’s a lot of truth to that, just in terms of general IT modernization. The cloud simply makes security easier. Not “easy” — there are still challenges. But you’re much more equipped to do the right thing—to build automation, to build tooling, and to take full advantage of the base protections that are built into the platform. With a little bit of care, what you do is going to be better than what you did before. The responsibility that remains for you as the customer is still significant, but because everything is software-defined, you get far more visibility and control. Because everything is API-driven, you can automate just about everything.

Challenges remain; I want to reiterate that it’s never easy to do security right. But it’s so much easier when you don’t have to run the entire stack from the concrete floor up to the application, and when you can rely on the inherent visibility and control provided by a software-defined environment. In short, cloud migration represents the industry’s best opportunity for making big improvements in IT security. I love being in the center of that change for the better, and helping to make it real.

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

Two things. First, we’re laser-focused on improving our AWS Identity and Access Management capabilities. They’re already very sophisticated and very powerful, but they are somewhat uneven across our services, and not as easy to use as they should be. I’m on the periphery of that work, but I’m actively involved in scoping out improvements. One recent example is a big advance in the capabilities of Service Control Policies (SCPs) within AWS Organizations. These now allow extremely fine-grained controls — as expressive as IAM polices—that can easily be applied globally across dozens or hundreds of AWS accounts. For example, you can express a global policy like “nobody but [some very special role] can attach an internet gateway to my VPCs, full stop.”

I’m also a networking geek, and another area I’ve been actively working on is improvements to our built-in networking security features. People have been asking for greater visibility and control over their VPCs. We have a lot of great features like security groups and network ACLs, but there’s a lot more we can and will do. For example, customers are looking for more visibility into what’s going on inside their VPCs beyond our existing VPC Flow Logs feature. We have an exciting announcement at our re:Inforce conference this week about some new capabilities in this area!

You’ll be speaking at re:Inforce about the security benefits of running EC2 instances on the AWS Nitro architecture. At a high level, what’s so innovative about Nitro, and how does it enable better security?

The EC2 Nitro architecture is a fundamental re-imagining of the best way to build a secure virtualization platform. I don’t think there’s anything else like it in the industry. We’ve taken a lot of the complicated software that’s needed for virtualization, which normally runs in a privileged copy of an operating system — the “domain 0,” or “dom0” to use Xen terminology, but present in all modern hypervisors — and we’ve completely eliminated it. All those features are now implemented by custom software and hardware in a set of powerful co-processor computers inside the same physical box as the main Intel processor system board. The Nitro computers present virtual devices to the mainboard as if they were actual hardware devices. You might say the main system board — despite its powerful Intel Xeon processor and big chunks of memory — is really the “co-processor” in these systems; I call it the “customer workload co-processor!” It’s the main Nitro controller and not the system mainboard that’s fundamentally in charge of the overall system, providing a root of trust and a secure layer between the mainboard and the outside world.

There are bunch of great security benefits that flow from this redesign. For example, with the elimination of the dom0 trusted operating system running on the mainboard, we’ve completely eliminated interactive access to these hosts. There’s no SSH, no RDP, no interactive software mechanisms that allow direct human access. I could go on and on, but I’ll stop there — you’ll have to come to my talk on Wednesday! And of course, we’ll post the video online afterward.

You’re also involved with a session to encourage customers to set up “state-of-the-art encryption.” In your view, what are some of the key elements of a “state-of-the-art” approach to encryption?

I came up with the original idea for the session, but was able to hand it off to an even better-suited speaker, so now I’ll just be there to enjoy it. Colm MacCarthaigh will be presenting. Colm is a senior principal engineer in the EC2 networking team, but he’s also the genius behind a number of important innovations in security and networking across AWS. For example, he did some of the original design work on the “shuffle sharding” techniques we use broadly, across AWS, to improve availability and resiliency for multi-tenanted services. Later, he came up with the idea, and, in a few weeks of intense coding, wrote the first version of S2N, our open source TLS implementation that provides far better security than the implementations typically used in the industry. He was also a significant contributor to the TLS 1.3 specification. I encourage everyone to follow him on Twitter, where you’ll learn all kinds of interesting things about cryptography, networking, and the like.

Now, to finally answer your question: Colm will be talking about how AWS does more and more encryption for you automatically, and how multiple layers of encryption can help address different kinds of threats. For example, without actually breaking TLS encryption, researchers have shown that they can figure out the content of an encrypted voice-over-IP (VOIP) call simply by analyzing the timing and size of the packets. So, wrapping TLS sessions inside of other encryption layers is a really good idea. Colm will talk about the importance of layered encryption, plus a bunch of other great topics: how AWS makes it easy to use encryption; where we do it automatically even if you don’t ask for it; how we’re inventing new, more secure means for key distribution; and fun stuff like that. It will be a blast!

What changes do you hope we’ll see across the global security and compliance landscape over the next 5 years?

I think that with innovations like the Nitro architecture for EC2, and with our commitment to continually improving and strengthening other security features and enabling greater automation around things like identity management and anomaly detection, we will come to a point where people will realize that the cloud, in almost every case, is more secure than an on-premises environment. I don’t mean to say that you couldn’t go outside of the cloud and build something secure (as long as you are willing to spend a ton of money). But as a general matter, cloud will become the default option for secure processing of very sensitive data.

We’re not quite there yet, in terms of widespread perception and understanding. There are still quite a few people who haven’t dug very far below the surface of “what is cloud.” There is still a common, visceral reaction to the idea of “public cloud” as being risky. People object to ideas like multitenancy, where you’re sharing physical infrastructure with other customers, as if it’s somehow inherently risky. There are risks, but they are so well mitigated, and we have so much experience controlling those risks, that they’re far outweighed by the big security benefits. Very consistently, as customers become more educated and experienced with the cloud, they tell us that they feel more secure in their cloud infrastructure than they did in their on-premises world. Still, that’s not currently the first reaction. People still start by thinking of the cloud as risky, and it takes time to educate them and change that perspective. So there’s still some important work ahead of us.

What’s your favorite way to relax?

It’s funny, now that I’m getting old, I’m reverting to some of the pursuits and hobbies of my youth. When I was a teenager I was passionate about cycling. I raced bicycles extensively at the regional and national level on both road and track from ages 14 to 18. A few minutes of my claim to 15 minutes of Warholian fame was used up by being in a two-man breakaway with 17-year-old Greg LeMond in a road race in Arizona, although he beat me and everyone else resoundingly in the end! I’ve ridden road bikes and done a bit of mountain biking over the years, but I’m getting back into it now and enjoying it immensely. Of course, there’s far more technology to play with these days, and I can’t resist. I splurged on an expensive pair of pedals with power meters built in, and so now I get detailed data from every ride that I can analyze to prove mathematically that I’m not in very good shape.

One of my other hobbies back in my teenage years was playing guitar — mostly folk-rock acoustic, but also electric and bass guitar in garage bands. That’s another activity I’ve started again. Fortunately, my kids, who are now around college-age plus or minus, all love the music from the 60s and 70s that I dust off and play, and they have great voices, so we have a lot of fun jamming and singing harmonies together.

What’s one thing that a visitor to your hometown of Washington, DC should experience?

The Washington DC area is famous for lots of great tourist attractions. But if you enjoy Michelin Guide-level dining experiences, I’d recommend a restaurant right in my neighborhood. It’s called L’Auberge Chez François, and it’s quite famous. It features Alsatian food (from the eastern region of France, along the German border). It’s an amazing restaurant that’s been there for almost 50 years, and it continues to draw a clientele from across the region and around the world. It’s always packed, so get reservations well in advance!

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.


Mark Ryland

Mark is the director of the Office of the CISO for AWS. He has more than 28 years of experience in the technology industry and has served in leadership roles in cybersecurity, software engineering, distributed systems, technology standardization and public policy. Prior to his current role, he served as the Director of Solution Architecture and Professional Services for the AWS World Public Sector team.

AWS Security Profiles: Fritz Kunstler, Principal Consultant, Global Financial Services

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-fritz-kunstler-principal-consultant-global-financial-services/

In the weeks leading up to re:Inforce, 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 here for three years. My job is Security Transformation, which is a technical role in AWS Professional Services. It’s a fancy way of saying that I help customers build the confidence and technical capability to run their most sensitive workloads in the AWS Cloud. Much of my work lives at the intersection of DevOps and information security.

Broadly, how does the role of Consultant differ from positions like “Solutions Architect”?

Depth of engagement is one of the main differences. On many customer engagements, I’m involved for three months, or six months, or nine months. I have one customer now that I’ve been working with for more than a year. Consultants are also more integrated—I’m often embedded in the customer’s team, working side-by-side with their employees, which helps me learn about their culture and needs.

What’s your favorite part of your job?

There’s a lot I like about working at Amazon, but a couple of things stand out. First, the people I work with. Amazon culture—and the people who comprise that culture—are amazing. I’m constantly interacting with really smart people who are willing to go out of their way to make good things happen for customers. At companies I’ve worked for in the past, I’ve encountered individuals like this. But being surrounded by so many people who behave like this day in and day out is something special.

The customers that we have the privilege of working with at AWS also represent some very large brands. They serve many, many consumers all over the world. When I help these customers achieve their security and privacy goals, I’m doing something that has an impact on the world at large. I’ve worked in tech my entire career, in roles ranging from executive to coder, but I’ve never had a job that lets me make such a broad impact before. It’s really cool.

What does cloud security mean to you, personally?

I work in Global Financial Services, so my customers are the world’s biggest banks, investment firms, and independent software vendors. These are companies that we all rely on every day, and they put enormous effort into protecting their customers’ data and finances. As I work to support their efforts, I think about it in terms of my wife, kids, parents, siblings—really, my entire extended family. I’m working to protect us, to ensure that the online world we live in is a safer one.

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

How to transform the way they do security. It’s not only a technical challenge—it’s a human challenge. For FinServe customers to get the most value out of the cloud, a lot of people need to be willing to change their minds.

Highly regulated customers like financial services firms tend to have sophisticated security organizations already in place. They’ve been doing things effectively in a particular way for quite a while. It takes a lot of evidence to convince them to change their processes—and to convince them that those changes can drive increased value and performance while reducing risk. Security leaders tend to be a skeptical lot, and that has its place, but I think that we should strive to always be the most optimistic people in the room. The cloud lets people experiment with big ideas that may lead to big innovation, and security needs to enable that. If the security leader in the room is always saying no, then who’s going to say yes? That’s the essence of security transformation – developing capabilities that enable your organization to say yes.

What’s a trend you see currently happening in the Financial Services space that you’re excited about?

AWS has been working hard alongside some of our financial services customers for several years. Moving to the cloud is a big transition, and there’s been some FUD—some fear, uncertainty, and doubt—to work through, so not everyone has been able to adopt the cloud as quickly as they might’ve liked. But I feel we’re approaching an inflection point. I’m seeing increasing comfort, increasing awareness, and an increasingly trained workforce among my customers.

These changes, in conjunction with executive recognition that “the cloud” is not only worthwhile, but strategically significant to the business, may signal that we’re close to a breakthrough. These are firms that have the resources to make things happen when they’re ready. I’m optimistic that even the more conservative of our financial services customers will soon be taking advantage of AWS in a big way.

Five years from now, what changes do you think we’ll see across the Financial Services/Cloud Security landscape?

I think cloud adoption will continue to accelerate on the business side. I also expect to see the security orgs within these firms leverage the cloud more for their own workloads – in particular, to integrate AI and machine learning into security operations, and further left in the systems development lifecycle. Security teams still do a lot of manual work to analyze code, policies, logs, and so on. This is critical stuff, but it’s also very time consuming and much of it is ripe for automation. Skilled security practitioners are in high demand. They should be focused on high-value tasks that enable the business. Amazon GuardDuty is just one example of how security teams can use the cloud toward that end.

What’s one thing that people outside of Financial Services can learn from what’s happening in this industry?

As more and more Financial Services customers adopt AWS, I think that it becomes increasingly hard for leaders in other sectors to suggest that the cloud isn’t secure, reliable, or capable enough for any given use case. I love the quote from Capital One’s CIO about why they chose AWS.

You’re leading a re:Inforce session that focuses on “IAM strategy for financial services.” What are some of the unique considerations that the financial services industry faces when it comes to IAM?

Financial services firms and other highly regulated customers tend to invest much more into tools and processes to enforce least privilege and separation of duties, due to regulatory and compliance requirements. Traditional, centralized approaches to implementing those two principles don’t always work well in the cloud, where resources can be ephemeral. If your goal is to enable builders to experiment and fail fast, then it shouldn’t take weeks to get the approvals and access required for a proof-of-concept than can be built in two days.

AWS Identity and Access Management (IAM) capabilities have changed significantly in the past year. Those changes make it easier and safer than ever to do things like delegate administrative access to developers. But they aren’t the sort of high-profile announcement that you’d hear a keynote speaker talk about at re:Invent. So I think a lot of customers aren’t fully aware of them, or of what you can accomplish by combining them with automation and CI/CD techniques.

My talk will offer a strategy and examples for using those capabilities to provide the same level of security—if not a better level of security—without so many of the human reviews and approvals that often become bottlenecks.

What are you hoping that your audience will do differently as a result of attending your session?

I’d like them to investigate and holistically implement the handful of IAM capabilities that we’ll discuss during the session. I also hope that they’ll start working to delegate IAM responsibilities to developers and automate low-value human reviews of policy code. Finally, I think it’s critical to have CI/CD or other capabilities that enable rapid, reliable delivery of updates to IAM policies across many AWS accounts.

Can you talk about some of the recent enhancements to IAM that you’re excited about?

Permissions boundaries and IAM resource tagging are two features that are really powerful and that I don’t see widely used today. In some cases, customers may not even be aware of them. Another powerful and even more recent development is the introduction of conditional support to the service control policy mechanism provided by AWS Organizations.

You’re an avid photographer: What’s appealing to you about photography? What’s your favorite photo you’ve ever taken?

I’ve always struggled to express myself artistically. I take a very technical, analytical approach to life. I started programming computers when I was six. That’s how I think. Photography is sufficiently technical for me to wrap my brain around, which is how I got started. It took me a long time to begin to get comfortable with the creative aspects. But it fits well with my personality, while enabling expression that I’d never be able to find, say, as a painter.

I won’t claim to be an amazing photographer, but I’ve managed a few really good shots. The photo that comes to mind is one I captured in Bora Bora. There was a guy swimming through a picturesque, sheltered part of the ocean, where a reef stopped the big waves from coming in. This swimmer was towing a surfboard with his dog standing on it, and the sun was going down in the background. The colors were so vibrant it felt like a Disneyland attraction, and from a distance, you could just see a dog on a surfboard. Everything about that moment – where I was, how I was feeling, how surreal it all was, and the fact that I was on a honeymoon with my wife – made for a poignant photo.

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

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author photo

Fritz Kunstler

Fritz is a Principal Consultant in AWS Professional Services, specializing in security. His first computer was a Commodore 64, which he learned to program in BASIC from the back of a magazine. Fritz has spent more than 20 years working in tech and has been an AWS customer since 2008. He is an avid photographer and is always one batch away from baking the perfect chocolate chip cookie.

AWS Security Profiles: Matthew Campagna, Sr. Principal Security Engineer, Cryptography

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-matthew-campagna-sr-principal-security-engineer-cryptography/

AWS Security Profiles: Matthew Campagna, Senior Principal Security Engineer, Cryptography

In the weeks leading up to re:Inforce, 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 almost 6 years. I joined as a Principal Security Engineer, but my focus has always been cryptography. I’m a cryptographer. At the start of my Amazon career, I worked on designing our AWS Key Management Service (KMS). Since then, I’ve gotten involved in other projects—working alongside a group of volunteers in the AWS Cryptography Bar Raisers group.

Today, the Crypto Bar Raisers are a dedicated portion of my team that work with any AWS team who’s designed a novel application of cryptography. The underlying cryptographic mechanisms aren’t novel, but the engineer has figured out how to apply them in a non-standard way, often to solve a specific problem for a customer. We provide these AWS employees with a deep analysis of their applications to ensure that the applications meet our high cryptographic security bar.

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

I usually tell people that I’m a mathematician. Sometimes I’ll explain that I’m a cryptographer. If anyone wants detail beyond that, I say I design security protocols or application uses of cryptography.

What’s the most challenging part of your job?

I’m convinced the most challenging part of any job is managing email.

Apart from that, within AWS there’s lots of demand for making sure we’re doing security right. The people who want us to review their projects come to us via many channels. They might already be aware of the Crypto Bar Raisers, and they want our advice. Or, one of our internal AWS teams—often, one of the teams who perform security reviews of our services—will alert the project owner that they’ve deviated from the normal crypto engineering path, and the team will wind up working with us. Our requests tend to come from smart, enthusiastic engineers who are trying to deliver customer value as fast as possible. Our ability to attract smart, enthusiastic engineers has served us quite well as a company. Our engineering strength lies in our ability to rapidly design, develop, and deploy features for our customers.

The challenge of this approach is that it’s not the fastest way to achieve a secure system. That is, you might end up designing things before you can demonstrate that they’re secure. Cryptographers design in the opposite way: We consider “ability to demonstrate security” in advance, as a design consideration. This approach can seem unusual to a team that has already designed something—they’re eager to build the thing and get it out the door. There’s a healthy tension between the need to deliver the right level of security and the need to deliver solutions as quickly as possible. It can make our day-to-day work challenging, but the end result tends to be better for customers.

Amazon’s s2n implementation of the Transport Layer Security protocol was a pretty big deal when it was announced in 2015. Can you summarize why it was a big deal, and how you were involved?

It was a big deal, and it was a big decision for AWS to take ownership of the TLS libraries that we use. The decision was predicated on the belief we could do a better job than other open source TLS packages by providing a smaller, simpler—and inherently more secure—version of TLS that would raise the security bar for us and for our customers.

To do this, the Automated Reasoning Group demonstrated the formal correctness of the code to meet the TLS specification. For the most part, my involvement in the initial release was limited to scenarios where the Amazon contributors did their own cryptographic implementations within TLS (that is, within the existing s2n library), which was essentially like any other Crypto Bar Raiser review for me.

Currently, my team and I are working on additional developments to s2n—we’re deploying something called “quantum-safe cryptography” into it.

You’re leading a session at re:Inforce that provides “an introduction to post-quantum cryptography.” How do you explain post-quantum cryptography to a beginner?

Post-quantum cryptography, or quantum-safe cryptography, refers to cryptographic techniques that remain secure even against the power of a large-scale quantum computer.

A quantum computer would be fundamentally different than the computers we use today. Today, we build computers based off of certain mathematical assumptions—that certain cryptographic ciphers cannot be cracked without an immense, almost impossible amount of computing power. In particular, a basic assumption that cryptographers build upon today is that the discreet log problem, or integer factorization, is hard. We take it for granted that this type of problem is fundamentally difficult to solve. It’s not a task that can be completed quickly or easily.

Well, it turns out that if you had the computing power of a large-scale quantum computer, those assumptions would be incorrect. If you could figure out how to build a quantum computer, it could unravel the security aspects of the TLS sessions we create today, which are built upon those assumptions.

The reason that we take this “if” so seriously is that, as a company, we have data that we know we want to keep secure. The probability of such a quantum computer coming into existence continues to rise. Eventually, the probability that a quantum computer exists during the lifetime of the sensitivity of the data we are protecting will rise above the risk threshold that we’re willing to accept.

It can take 10 to 15 years for the cryptographic community to study new algorithms well enough to have faith in the core assumptions about how they work. Additionally, it takes time to establish new standards and build high quality and certified implementations of these algorithms, so we’re investing now.

I research post-quantum cryptographic techniques, which means that I’m basically looking for quantum-safe techniques that can be designed to run on the classical computers that we use now. Identifying these techniques lets us implement quantum-safe security well in advance of a quantum computer. We’ll remain secure even if someone figures out how to create one.

We aren’t doing this alone. We’re working within in the larger cryptographic community and participating in the NIST Post-Quantum Cryptography Standardization process.

What do you hope that people will do differently as a result of attending your re:Inforce session?

First, I hope people download and use s2n in any form. S2n is a nice, simple Transport Layer Socket (TLS) implementation that reduces overall risk for people who are currently using TLS.

In addition, I’d encourage engineers to try the post-quantum version of s2n and see how their applications work with it. Post-quantum cryptographic schemes are different. They have a slightly different “shape,” or usage. They either take up more bandwidth, which will change your application’s latency and bandwidth use, or they require more computational power, which will affect battery life and latency.

It’s good to understand how this increase in bandwidth, latency, and power consumption will impact your application and your user experience. This lets you make proactive choices, like reducing the frequency of full TLS handshakes that your application has to complete, or whatever the equivalent would be for the security protocol that you’re currently using.

What implications do post-quantum s2n developments have for the field of cloud security as a whole?

My team is working in the public domain as much as possible. We want to raise the cryptography bar not just for AWS, but for everyone. In addition to the post-quantum extension to s2n that we’re writing, we’re writing specifications. This means that any interested party can inspect and analyze precisely how we’re doing things. If they want to understand nuances of TLS 1.2 or 1.3, they can look at those specifications, and see how these post-quantum extensions apply to those standards.

We hope that documenting our work in the public space, where others can build interoperable systems, will raise the bar for all cloud providers, so that everyone is building upon a more secure foundation.

What resources would you recommend to someone interested in learning more about s2n or post-quantum cryptography?

For s2n, we do a lot of our communication through Security Blog posts. There’s also the AWS GitHub repository, which houses our source code. It’s available to anyone who wants to look at it, use it, or become a contributor. Any issues that arise are captured in issue pages there.

For quantum-safe crypto, a fairly influential paper was released in 2015. It’s the European Telecommunications Standards Institute’s Quantum-Safe Whitepaper (PDF file). It provides a gentle introduction to quantum computing and the impact it has on information systems that we’re using today to secure our information. It sets forth all of the reasons we need to invest now. It helped spur a shift in thinking about post-quantum encryption, from “research project” to “business need.”

There are certainly resources that allow you to go a lot deeper. There’s a highly technical conference called PQ Crypto that’s geared toward cryptographers and focuses on post-quantum crypto. For resources ranging from executive to developer level, there’s a quantum-safe cryptography workshop organized every year by the Institute for Quantum Computing at the University of Waterloo (IQC) and the European Telecommuncations Standards Institute (ETSI). AWS is partnering with ETSI/IQC to host the 2019 workshop in Seattle.

What’s one fact about cryptography that you think everyone—even laypeople—should be aware of?

People sometimes speak about cryptography like it’s a fact or a mathematical science. And it’s not, precisely. Cryptography doesn’t guarantee outcomes. It deals with probabilities based upon core assumptions. Cryptographic engineering requires you to understand what those assumptions are and closely monitor any challenges to them.

In the business world, if you want to keep something secret or confidential, you need to be able to express the probability that the cryptographic method fails to provide the desired security property. Understanding this probability is how businesses evaluate risk when they’re building out a new capability. Cryptography can enable new capabilities that might otherwise represent too high a risk. For instance, public-key cryptography and certificate authorities enabled the development of the Secure Socket Layer (SSL) protocol, and this unlocked e-Commerce, making it possible for companies to authenticate to end users, and for end users to engage in a confidential session to conduct business transactions with very little risk. So at the end of the day, I think of cryptography as essentially a tool to reduce the risk of creating new capabilities, especially for business.

Anything else?

Don’t think of cryptography as a guarantee. Think about it as a probability that’s tied to how often you use the cryptographic method.

You have confidentiality if you use the system based on an assumption that you can understand, like “this cryptographic primitive (or block cipher) is a pseudo-random permutation.” Then, if you encrypt 232 messages, the probability that all your data stays secure (confidential or authentic) is, let’s say, 2-72. Those numbers are where people’s eyes may start to gloss over when they hear them, but most engineers can process that information if it’s written down. And people should be expecting that from their solutions.

Once you express it like that, I think it’s clear why we want to move to quantum-safe crypto. The probabilities we tolerate for cryptographic security are very small, typically smaller than 2-32, around the order of one in four billion. We’re not willing to take much risk, and we don’t typically have to from our cryptographic constructions.

That’s especially true for a company like Amazon. We process billions of objects a day. Even if there’s a one in the 232 chance that some information is going to spill over, we can’t tolerate such a probability.

Most of cryptography wasn’t built with the cloud in mind. We’re seeing that type of cryptography develop now—for example, cryptographic computing models where you encrypt the data before you store it in the cloud, and you maintain the ability to do some computation on its encrypted form, and the plaintext never exists within the cloud provider’s systems. We’re also seeing core crypto primitives, like the Advanced Encryption Standard, which wasn’t designed for the cloud, begin to show some age. The massive use cases and sheer volume of things that we’re encrypting require us to develop new techniques, like the derived-key mode of AES-GCM that we use in AWS KMS.

What does cloud security mean to you, personally?

I’ll give you a roundabout answer. Before I joined Amazon, I’d been working on quantum-safe cryptography, and I’d been thinking about how to securely distribute an alternative cryptographic solution to the community. I was focused on whether this could be done by tying distribution into a user’s identity provider.

Now, we all have a trust relationship with some entity. For example, you have a trust relationship between yourself and your mobile phone company that creates a private, encrypted tunnel between the phone and your local carrier. You have a similar relationship with your cable or internet provider—a private connection between the modem and the internet provider.

When I looked around and asked myself who’d make a good identity provider, I found a lot of entities with conflicting interests. I saw few companies positioned to really deliver on the promise of next-generation cryptographic solutions, but Amazon was one of them, and that’s why I came to Amazon.

I don’t think I will provide the ultimate identity provider to the world. Instead, I’ve stayed to focus on providing Amazon customers the security they need, and I’m thrilled to be here because of the sheer volume of great cryptographic engineering problems that I get to see on a regular basis. More and more people have their data in a cloud. I have data in the cloud. I’m very motivated to continue my work in an environment where the security and privacy of customer data is taken so seriously.

You live in the Seattle area: When friends from out of town visit, what hidden gem do you take them to?

When friends visit, I bring them to the Amazon Spheres, which are really neat, and the MoPOP museum. For younger people, children, I take them on the Seattle Underground Tour. It has a little bit of a Harry Potter-like feel. Otherwise, the great outdoors! We spend a lot of time outside, hiking or biking.

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

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Campagna bio photo

Matthew Campagna

Matthew is a Sr. Principal Engineer for Amazon Web Services’s Cryptography Group. He manages the design and review of cryptographic solutions across AWS. He is an affiliate of Institute for Quantum Computing at the University of Waterloo, a member of the ETSI Security Algorithms Group Experts (SAGE), and ETSI TC CYBER’s Quantum Safe Cryptography group. Previously, Matthew led the Certicom Research group at BlackBerry managing cryptographic research, standards, and IP, and participated in various standards organizations, including ANSI, ZigBee, SECG, ETSI’s SAGE, and the 3GPP-SA3 working group. He holds a Ph.D. in mathematics from Wesleyan University in group theory, and a bachelor’s degree in mathematics from Fordham University.

AWS Security Profiles: Stephen Quigg, Principal Security Solutions Architect, Financial Services Industry

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-stephen-quigg-principal-security-solutions-architect-financial-services-industry/

AWS Security Profiles: Stephen Quigg, Principal Security Solutions Architect, Financial Services Industry

In the weeks leading up to re:Inforce, 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 as a Principal Security Solutions Architect?

I’ve been with AWS for six years and four months. My job is to help customers get comfortable with the security measures that AWS takes on their behalf—measures which help customers build secure applications on top of our services. I help them understand both sides of the Shared Responsibility Model.

What’s your favorite part of your job?

Being thrust into a room full of security professionals who don’t have experience with AWS. They’re understandably wary of trying new things, so I’m happy when I see their attitudes and moods change. Once they begin to understand how I can help them, they start nodding their heads and uncrossing their arms.

What’s the most challenging part of your job?

When I present customers with a logical argument, some of them still won’t be reassured. I can ask “why not?” but they might not be able to explain. That’s a tough situation, because those are the people that my team needs to keep talking to. We need to keep trying to understand what drives their concerns about cloud security, and what needs to happen for them to make the shift. It’s not effective to tell people that they’re wrong. You have to understand their needs, explain things, and let them draw their own conclusions.

When I look at our customers’ information security teams, these teams are just people like me, who are often stuck in very difficult situations. They might not have the resources or the time to do all the things they want to do, and they probably have to interact with a lot of people who think of them as blockers, even though their job is to protect the company. AWS represents a wonderful opportunity for change. I want to show them a new style of service, and that we’re listening to them, and that we’re acting in their best interest.

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

The biggest challenge for our customers is that they already have so much work to do. And when their businesses start transitioning to AWS, their security teams now have new work.

Their ability to do all of that work can be improved through the advanced automation that AWS offers. But we need to help our customers learn how to build automated solutions. We offer wonderful services, and we can help people stitch them together, but all of this represents a new “cloud security” operating model that customers often have to start up while still maintaining their existing operating model.

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

Many incidents that currently require a human response will be dealt with automatically. Beyond that, the ability to automatically analyze the evidence to figure out what went wrong, and what to do about it is where we’ll see big developments.

I think the other big change is that customers will start worrying less about high-touch processes like patching, because they’ll have automated the process of building new things. There will still be vulnerabilities—there will always be vulnerabilities—but these types of changes will be helpful because it will mean fewer people logged onto production servers. We’re moving toward a zero-touch environment where, barring extreme emergencies, everything can be done via automation.

It’s typically human error that causes security incidents. It’s not malicious, it’s just that people make mistakes. And the fewer the number of people involved, the fewer the number of mistakes that can happen, because you can automate code testing to make sure it’s working properly. It’s hard to have that level of assurance when we’re talking about a person’s fingers on a keyboard.

How does working in a highly regulated industry like financial services affect the work that you do as a solutions architect?

I have to be really diligent about listening. I can’t answer customer requests by painting with broad brushstrokes and saying “close enough.” Many AWS customers are regulated. They have strict requirements from their regulators that they have to meet. AWS can’t make assumptions that something is “good enough.” The customer has to make those decisions.

So it’s important to be very precise about what you tell customers, and it’s important to be very transparent, and to give them very accurate information, because they’ll need to be able to prove that they understand the AWS cloud when they talk to their regulators. It’s not good enough for AWS to talk on their behalf.

What does cloud security mean to you, personally?

I love technology and security. Since 1999, when I first started working full-time as a security professional, my singular point of focus has been information security. Back then, my job was to help advise people on security architecture and to do pen testing. And during those years, I watched a lot of people fail: The solutions they bought were the equivalent of trying to patch up a wound with sticking plasters. The solutions rarely worked.

What drives me today is that after six years at AWS, I still absolutely love it. I’m a part of one of the biggest improvements that has ever happened to information security. The ability of customers to automate tasks, plus the ability to pass management of really complex architecture to a cloud provider that is focused on security, a provider that “does security” as its core competency, its core business—that thrills me.

I see all these opportunities for our customers, and I want them all to succeed, because everyone benefits from a more secure world. I benefit from a life where I can do my banking on my phone, and where I can video call from anywhere. My family and my children will benefit from this world.

You’re co-hosting a session at re:Inforce that focuses on “When and how” to use AWS CloudHSM. When should you use CloudHSM, and what’s the alternative?

You should choose AWS CloudHSM when you have strict compliance requirements that require cryptographic operations to be performed within a FIPS 140-2 Level 3 validated device, which is what CloudHSM is. You should use it when you can’t use any other AWS cryptographic service.

CloudHSM is a really important service for a small set of customers that really need it. Many of our customers’ needs are actually more easily served by other AWS services. And those services often require less skill to set up, and less attention from the customer. CloudHSM, by its very nature, gives customers a lot of responsibility. If you’re able to pick other AWS cryptographic services, AWS can do much more of the work.

You’re also hosting a builders session. What can you tell us about that topic?

Many people who are new to the cloud come from a traditional security architecture background, so we need to teach them about architecture in the cloud. Automation is really, really important in the cloud, but to get to the point where you can automate everything, there’s a lot you need to design and build.

Many of our customers in financial services also care very deeply about how things connect to the internet, whether it’s traffic that’s coming to their Amazon Elastic Compute Cloud (EC2) instances or traffic from their EC2 instances that’s going back out to the internet.

So I’ve designed a session to help those people get comfortable with how to take traditional security architecture and rethink it for AWS. This moves them one step closer to the cloud. The session includes stepping stones between what you’re doing on-premise and how you can do it in the cloud. I want to help people get comfortable and realize that the shift isn’t as large as they thought it was. The session will cover topics like firewalls, inbound and outbound proxies, and web application firewalls; all things that are easily built on top of AWS services.

What do you hope that people will do differently as a result of attending your sessions?

The CloudHSM session is deep dive into how customers can optimize their use of the service in terms of cost, performance, and resilience.

I’m hoping that the people who attend the session are either planning a deployment of CloudHSM or have existing deployments that they want to look at in terms of those three levers—cost, performance, and resilience. I want people to review their requirements and ask, “Am I using too many CloudHSMs? Have I provisioned too many?” There might be an opportunity to save money. Or, “Am I built resiliently enough? Do I have CloudHSMs deployed in multiple Availability Zones, or maybe in multiple Regions?” And finally, “Am I using the right AWS crypto service? Do I really need a CloudHSM, or should I be using AWS Key Management Service or AWS Certificate Manager instead?”

For the second session on modernizing security architecture, I’d like people to go home and start thinking about moving their data centers to AWS. I’d like to be the catalyst. Earlier, I mentioned some of the challenges customers can face when transitioning to security in the cloud—I hope my session will help attendees start thinking through the logistics of that transition.

Anything else about either session you want us to know about?

Yes. I am not a cryptographer, so someone from the AWS cryptography team is going to co-host the CloudHSM deep-dive. When I’m speaking to my customers, I always try to be very clear about this point. The one thing you should never wave your arms and be vague about is cryptography. I think cryptography on its own is fascinating, so I’m humbled by the fact that I will never be a cryptographer.

Have you been to Boston before? Is there anything that you’re looking forward to seeing or doing while you’re there?

I’ve never been to Boston, and I’m really looking forward to it. It seems like a beautiful city, and I’m excited about experiencing its atmosphere and its character as an historic European point of entry into America. Every American city has such a different character, so I’m looking forward to experiencing Boston. It’s also the city one of my favorite Neal Stephenson books was based in – Zodiac!

You make music, with track titles like “Hardware Security Module – SHA-3.” How does your day job inform your music? (And vice versa?)

I love my electro music, and I love my techno. The origins of techno were in Detroit, where the sound was built based on the repetitive noise of machines. Now, I’m from near the Glasgow, Scotland area, and Glasgow was at the heart of the Industrial Revolution. It was called the “engine room of the Empire.” We had shipyards and production lines. So I think the people of Glasgow and the people of Detroit have a common tie in terms of the music that we like.

Working in technology fuels the same kind of inspiration for me. We’re in the middle of a new industrial revolution, and my work and my mood very much influence my music. I’m really happy working at AWS, and I get to work with absolutely awesome technology daily. This all bleeds into the music I make. (HSM and Detroit are my techno tracks, and HSM and Chicago are my acid house tracks.)

You live in Scotland. What’s one thing a visitor should see, eat, or do when visiting Scotland?

If I were from Edinburgh, I’d tell you to see Edinburgh Castle. But instead, I’d say that you must visit the West Coast. The West Coast is our islands and our mountains—places like Glencoe, if you can get there. Other countries have bigger mountains. Other countries have steeper cliffs. But there is a loneliness and a barrenness about Scotland that’s quite breathtaking, and that I’ve never found anywhere else in the world. The West Coast of Scotland is absolutely the place that you must experience if you visit the country. If you don’t, you won’t understand the whole “Scottish thing” that we have going on.

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

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

author photo

Stephen Quigg

Squigg started his AWS career in Sydney, Australia, but returned home to Scotland three years ago having missed the wind and rain too much. He manages to fit some work in between being a husband and father to two angelic children and making music.

AWS Security Profiles: Tracy Pierce, Senior Consultant, Security Specialty, Remote Consulting Services

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-tracy-pierce-senior-consultant-security-specialty-rcs/

AWS Security Profiles: Tracy Pierce, Senior Consultant, Security Specialty, Remote Consulting Services

In the weeks leading up to re:Inforce, 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.

You’ve worn a lot of hats at AWS. What do you do in your current role, and how is it different from previous roles?

I joined AWS as a Customer Support Engineer. Currently, I’m a Senior Consultant, Security Specialty, for Remote Consulting Services, which is part of the AWS Professional Services (ProServe) team.

In my current role, I work with ProServe agents and Solution Architects who might be out with customers onsite and who need stuff built. “Stuff” could be automation, like AWS Lambda functions or AWS CloudFormation templates, or even security best practices documentation… you name it. When they need it built, they come to my team. Right now, I’m working on an AWS Lambda function to pull AWS CloudTrail logs so that you can see if anyone is making policy changes to any of your AWS resources—and if so, have it written to an Amazon Aurora database. You can then check to see if it matches the security requirements that you have set up. It’s fun! It’s new. I’m developing new skills along the way.

In my previous Support role, my work involved putting out fires, walking customers through initial setup, and showing them how to best use resources within their existing environment and architecture. My position as a Senior Consultant is a little different—I get to work with the customer from the beginning of a project rather than engaging much later in the process.

What’s your favorite part of your job

Talking with customers! I love explaining how to use AWS services. A lot of people understand our individual services but don’t always understand how to use multiple services together. We launch so many features and services that it’s understandably hard to keep up. Getting to help someone understand, “Hey, this cool new service will do exactly what I want!” or showing them how it can be combined in a really cool way with this other new service—that’s the fun part.

What’s the most challenging part of your job?

Right now? Learning to code. I don’t have a programming background, so I’m learning Python on the fly with the help of some teammates. I’m a very graphic-oriented, visual learner, so writing lines of code is challenging. But I’m getting there.

What career advice would you offer to someone just starting out at AWS?

Find a thing that you’re passionate about, and go for it. When I first started, I was on the Support team in the Linux profile, but I loved figuring out permissions and firewall rules and encryption. I think AWS had about ten services at the time, and I kept pushing myself to learn as much as I could about AWS Identity and Access Management (IAM). I asked enough questions to turn myself into an expert in that field. So, my best advice is to find a passion and don’t let anything hold you back.

What inspires you about security? Why is it something you’re passionate about?

It’s a puzzle, and I love puzzles. We’re always trying to stay one step ahead, which means there’s always something new to learn. Every day, there are new developments. Working in Security means trying to figure out how this ever-growing set of puzzles and pieces can fit together—if one piece could potentially open a back door, how can you find a different piece that will close it? Figuring out how to solve these challenges, often while others in the security field are also working on them, is a lot of fun.

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

There aren’t enough people focusing on cybersecurity. We’re in an era where people are migrating from on-prem to cloud, and it requires a huge shift in mindset to go from working with on-prem hardware to systems that you can no longer physically put your hands on. People are used to putting in physical security restraints, like making sure doors locks and badges are required for entry. When you move to the cloud, you have to start thinking not just about security group rules—like who’s allowed access to your data—but about all the other functions, features, and permissions that are a part of your cloud environment. How do you restrict those permissions? How do you restrict them for a certain team versus certain projects? How can you best separate job functions, projects, and teams in your organization? There’s so much more to cybersecurity than the stories of “hackers” you see on TV.

What’s the most common misperception you encounter about cloud security?

That it’s a one-and-done thing. I meet a lot of people who think, “Oh, I set it up” but who haven’t touched their environment in four years. The cloud is ever-changing, so your production environment and workloads are ever-changing. They’re going to grow; they’ll need to be audited in some fashion. It’s important to keep on top of that. You need to audit permissions, audit who’s accessing which systems, and make sure the systems are doing what they’re supposed to. You can’t just set it up and be finished.

How do you help educate customers about these types of misperceptions?

I go to AWS Pop-up Lofts periodically, plus conferences like re:Inforce and re:Invent, where I spend a lot of time helping people understand that security is a continuous thing. Writing blog posts also really helps, since it’s a way to show customers new ways of securing their environment using methods that they might not have considered. I can take edge cases that we might hear about from one or two customers, but which probably affect hundreds of other organizations, and reach out to them with some different setups.

You’re leading a re:Inforce builders session called “Automating password and secrets, and disaster recovery.” What’s a builders session?

Builders sessions are basically labs: There will be a very short introduction to the session, where you’re introduced to the concepts and services used in the lab. In this case, I’ll talk a little about how you can make sure your databases and resources are resilient and that you’ve set up disaster recovery scenarios.

After that, I walk around while people try out the services, hands-on, for themselves, and I see if anyone has questions. A lot of people learn better if they actually get a chance to play with things instead of just read about them. If people run into issues, like, “Why does the code say this for example?” or “Why does it create this folder over here in a different region?” I can answer those questions in the moment.

How did you arrive at your topic?

It’s based on a blog post that I wrote, called “How to automate replication of secrets in AWS Secrets Manager across AWS Regions.” It was a highly requested feature from customers that were already dealing with RDS databases. I actually wrote two posts–the second post focused on Windows passwords, and it demonstrated how you can have a secure password for Windows without having to share an SSH key across multiple entities in an organization. These two posts gave me the idea for the builders session topic: I want to show customers that you can use Secrets Manager to store sensitive information without needing to have a human manually read it in plain text.

A lot of customers are used to an on-premises access model, where everything is physical and things are written in a manual—but then you have to worry about safeguarding the manual so that only the appropriate people can read it. With the approach I’m sharing, you can have two or three people out of your entire organization who are in charge of creating the security aspects, like password policy, creation, rotation, and function. And then all other users can log in: The system pulls the passwords for them, inputs the passwords into the application, and the users do not see them in plain text. And because users have to be authenticated to access resources like the password, this approach prevents people from outside your organization from going to a webpage and trying to pull that secret and log in. They’re not going to have permissions to access it. It’s one more way for customers to lock down their sensitive data.

What are you hoping that your audience will do differently as a result of this session?

I hope they’ll begin migrating their sensitive data—whether that’s the keys they’re using to encrypt their client-side databases, or their passwords for Windows—because their data is safer in the cloud. I want people to realize that they have all of these different options available, and to start figuring ways to utilize these solutions in their own environment.

I also hope that people will think about the processes that they have in their own workflow, even if those processes don’t extend to the greater organization and it’s something that only affects their job. For example, how can they make changes so that someone can’t just walk into their office on any given day and see their password? Those are the kinds of things I hope people will start thinking about.

Is there anything else you want people to know about your session?

Security is changing so much and so quickly that nobody is 100% caught up, so don’t be afraid to ask for help. It can feel intimidating to have to figure out new security methods, so I like to remind people that they shouldn’t be afraid to reach out or ask questions. That’s how we all learn.

You love otters. What’s so great about them?

I’m obsessed with them—and otters and security actually go together! When otters are with their family group, they’re very dedicated to keeping outsiders away and not letting anybody or anything get into their den, into their home, or into their family. There are large Amazon river otters that will actually take on Cayman alligators, as a family group, to make sure the alligators don’t get anywhere near the nest and attack the pups. Otters also try to work smarter, not harder, which I’ve found to be a good motto. If you can accomplish your goal through a small task, and it’s efficient, and it works, and it’s secure, then go for it. That’s what otters do.

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

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.


Tracy Pierce

Tracy Pierce is a Senior Consultant, Security Specialty, for Remote Consulting Services. She enjoys the peculiar culture of Amazon and uses that to ensure every day is exciting for her fellow engineers and customers alike. Customer Obsession is her highest priority and she shows this by improving processes, documentation, and building tutorials. She has her AS in Computer Security & Forensics from SCTD, SSCP certification, AWS Developer Associate certification, and AWS Security Specialist certification. Outside of work, she enjoys time with friends, her Great Dane, and three cats. She keeps work interesting by drawing cartoon characters on the walls at request.

AWS Security Profiles: Paul Hawkins, Security Solutions Architect

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-paul-hawkins-security-solutions-architect/

Leading up to AWS Summit Sydney, we’re sharing our conversation with Paul Hawkins, who helped put together the summit’s “Secure” track, so you can learn more about him and some of the interesting work that he’s doing.

What does a day in the life of an AWS Security Solutions Architect look like?

That’s an interesting question because it varies a lot. As a Security Solutions Architect, I cover Australia and New Zealand with Phil Rodrigues—we split a rather large continent between us. Our role is to help AWS account teams help AWS customers with security, risk, and compliance in the cloud. If a customer is coming to the cloud from a on-premises environment, their security team is probably facing a lot of changes. We help those teams understand what it’s like to run security on AWS—how to think about the shared responsibility model, opportunities to be more secure, and ways to enable their businesses. My conversations with customers range from technical deep-dives to high-level questions about how to conceptualize security, governance, and risk in a cloud environment. A portion of my work also involves internal enablement. I can’t scale to talk to every customer, so teaching other customer-facing AWS teams how to have conversations about security is an important part of my role.

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

I say that my job has two functions. First, I explain complex things to people who are not experts in that domain so that they can understand how to do them. Second, I help people be more secure in the cloud. Sometimes I then have to explain what “the cloud” is. How I explain my job to friends reminds me of how I explain the cloud to brand new customers—people usually figure out how it works by comparing it to their existing mental models.

What’s your favorite part of your job?

Showing people that moving to the cloud doesn’t have to be scary. In fact, it’s often an opportunity to be more secure. The cloud is a chance for security folks—who have traditionally been seen as a “Department of No” or a blocker to the rest of the organization—to become an enabling function. Fundamentally, every business is about customer trust. And how do you make sure you maintain the trust of your customers? You keep their data secure. I get to help the organizations I work with to get applications and capabilities out to their customers more swiftly—and also more securely. And that’s a really great thing.

Professionally, what’s your background? What prompted you to move into the field of cloud security at AWS?

I used to work in a bank as a Security Architect. I was involved in helping the business move a bunch of workloads into AWS. In Australia, we have a regulator called APRA (the Australian Prudential Regulatory Authority). If you’re an insurance or financial services company who is running a material workload (that is, a workload that has a significant impact on the banking or financial services industry) you have to submit information to this regulator about how you’re going to run the workload, how you’re going to operationalize it, what your security posture looks like, and so on. After reviewing how you’re managing risk, APRA will hopefully give you a “no objection” response. I worked on the first one of those submissions in Australia.

Working in a bank with a very traditional IT organization and getting to bring that project over the finish line was a great experience. But I also witnessed a shift in perspective from other teams about what “security” meant. I moved from interacting with devs who didn’t want to come talk to us because we were the security folks to a point, just before I left, where I was getting emails from people in the dev and engineering teams, telling me how they built controls because we empowered them with the idea that “security is everyone’s job.” I was getting emails saying, “I built this control, but I think we can use it in other places!” Having the dev community actively working with the security team to make things better for the entire organization was an amazing cultural change. I wanted to do more work like that.

Are there any unique challenges—security or otherwise—that customers in New Zealand or Australia face when moving to the cloud?

If you look at a lot of regulators in this region, like the APRA, or an Australian government standard like IRAP, or compare these regulators with programs like FedRAMP in the US, you’ll see that everything tends to roll up toward requirements in the style of (for example) the NIST Cybersecurity Framework. When it comes to security, the fundamentals don’t change much. You need to identify who has access to your environment, you need to protect your network, you need good logging visibility, you need to protect data using encryption, and you need to have a mechanism for responding instantly to changes. I do think Australia has some interesting challenges in terms of the geographical size of the country, and the distant spread of population between the east and west coasts. Otherwise, the challenges are similar to what customers face globally: understanding shared responsibility, understanding how to build securely on the cloud, and understanding the differences from what they’ve traditionally been doing.

What’s the most common misperception you encounter about cloud security?

People think it’s a lot harder than it is. Some people also have the tendency to focus on esoteric edge cases, when the most important thing to get right is the foundation. And the foundation is actually straightforward: You follow best practices, and you follow the Well-Architected Framework. AWS provides a lot of guidance on these topics.

I talk to a lot of security folks, architects, instant responders, and CISOs, and I end up saying something similar to everyone: As you begin your cloud journey, you’ve probably got a hundred things you’re worried about. That’s reasonable. As a security person, your job is to worry about what can happen. But you should focus on the top five things that you need to do right now, and the top five things that are going to require a bit of thought across your organization. Get those things done. And then chip away at the rest—you can’t solve everything all at once. It’s better to get the foundations in and start building while raising your organization’s security bar, rather than spin your wheels for months because you can’t map out every edge case.

During the course of your work, what cloud security trends have you noticed that you’re excited about?

I’m really pleased to see more and more organizations genuinely embrace automation. Keeping humans away from systems is a great way to drive consistency: consistency of environments means you can have consistency of response, which is important for security.

As humans, we aren’t great at doing the same thing repeatedly. We’ll do okay for a bit, but then we get distracted. Automated systems are really good at consistently doing the same things. If you’re starting at the very beginning of an environment, and you build your AWS accounts consistently, then your monitoring can also be consistent. You don’t have to build a complicated list of exceptions to the rules. And that means you can have automation covering how you build environments, how you build applications into environments, and how to detect and respond in environments. This frees up the people in your organization to focus on the interesting stuff. If people are focused on interesting challenges, they’re going to be more engaged, and they’re going to deliver great things. No one wants to just put square pegs in square holes every day at work. We want to be able to exercise our minds. Security automation enables that.

What does cloud security mean to you, personally?

I genuinely believe that I have an incredible opportunity to help as many customers as possible be more secure in the cloud. “Being more secure in the cloud” doesn’t just mean configuring AWS services in a way that’s sensible—it also means helping drive cultural change, and moving peoples’ perceptions of security away from, “Don’t go talk to those people because they’re going to yell at you” to security as an enabling function for the business. Security boils down to “keeping the information of humans protected.” Whether that’s banking information or photos on a photo-sharing site, the fundamental approach should be the same. At the end of the day, we’re building things that humans will use. As security people, we need to make it easier for our engineers to build securely, as well as for end users to be confident their data is protected—whatever that data is.

I get to help these organizations deliver their services in a way that’s safer and enables them to move faster. They can build new features without having to worry about enduring a six-month loop of security people saying, “No, you can’t do that.” Helping people understand what’s possible with the technology and helping people understand how to empower their teams through that technology is an incredibly important thing for all parts of an organization, and it’s deeply motivating to me.

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

I believe the ways people think about security in the cloud will continue to evolve. AWS is releasing more higher-function services like Amazon GuardDuty and AWS Security Hub that make it easier for customers to be more secure. I believe people will become more comfortable using these tools as they start to understand that we’re devoting a huge amount of effort to making these services provide useful, actionable information for customers, rather than just being another set of logs to look at. This will allow customers to focus on the aspects of their organization that deliver business value, while worrying less about the underlying composition of services.

At the moment, people approach cloud security by applying a traditional security mindset. It’s normal to come to the cloud from a physical environment, where you could touch and see the servers, and you could see blinking lights. This background can color the ways that people think about the cloud. In a few years’ time, as people become more comfortable with this new way of thinking about security, I think customers will start to come to us right out of the gate with questions like, “What specifics services do I need, and how do I configure them to make my environment better?”

You’ve been involved in putting together the Security track at the upcoming AWS summit in Sydney. What were you looking for as you selected session topics?

We have ten talks in the “Secure” track, and we’ve selected topics to address as many customer needs as possible. That means sessions for people who are just getting started and have questions like, “What foundational things can I turn on to ensure I start my cloud journey securely?” It also means sessions for people who are very adept at using cloud services and want to know things like, “How do I automate incidence response and forensics?” We’ve also talked to people who run organizations that don’t even have a security team—often small startups—who want to get their heads wrapped around cloud security. So, hopefully we have sessions that appeal to a range of customers.

We’re including existing AWS customers in nine out of the ten talks. These customers fall across the spectrum, from some of our largest enterprise customers to public sector, startups, mid-market, and financial services. We’ve tried to represent both breadth and depth of customer stories, because we think these stories are incredibly important. We had a few customers in the track last year, and we got a great response from the audience, who appreciated the chance to hear from peers, or people in similar industries, about how they improved their security posture on AWS.

What do you hope people gain from attending the “Secure” track?

Regardless of the specific sessions that people attend, I want them walk away saying, “Wow, I can do this in my organization right now.” I want people to see the art of the possible for cloud security. You can follow the prescriptive advice from various talks, go out, and do things for your organization. It shouldn’t be some distant, future goal, either. We offer prescriptive guidance for what you can do right now.

Say you’re in a session about secrets management. We might say, This is the problem we’re talking about, this is how to approach it using AWS Identity and Access Management (IAM) roles, and if you can’t use AWS IAM roles, here how to use AWS Secrets Manager. Next, here’s a customer to talk about how they think of secrets management in a multi-account environment. Next, here are a bunch of different use cases. Finally, here are the places you can go for further information, and here’s how you can get started today.” My hope is that the talk inspires people to go and build and be more secure immediately. I want people to leave the Summit and immediately start building.

We’re really proud of the track. We’ve got a range of customer perspectives and a range of topics that hopefully covers as much of the amazing breadth of cloud security as we can fit into ten talks.

Sometimes you make music and post it to Soundcloud. Who are your greatest musical influences?

Argh. There are so many. I went through a big Miles Davis phase, more from listening than in any way capable of being that good. I also draw inspiration from shouty English punk bands like the Buzzcocks, plus quite a lot of hip-hop. That includes both classic hip-hop like De La Soul or A Tribe Called Quest and more recent stuff like Run the Jewels. They’re an American band out of Atlanta who I listen to quite a lot at the moment. There are a lot of different groups I could point to, depending on mood. I’ve been posting my music to Soundcloud for ten years or so. Long enough that I should be better. But it’s a journey, and of course time is a limiting factor—AWS is a very busy place.

We understand that you’ve switched from playing cricket to baseball. What turned you into a baseball fan?

I moved from Sydney to Melbourne. In Sydney, the climate is okay for playing outdoor cricket in the winter. But in Melbourne, it’s not really a winter sport. I was looking for something to do, so I started playing winter baseball with a local team. The next summer, I played both cricket and baseball—they were on different days—but it became quite confusing because there are some fundamental differences. I ended up enjoying baseball more, and it took a bit less time. Cricket is definitely a full day event. Plus, one of the great things about baseball is that as a hitter you’re sort of expected to fail 60% of the time. But you get another go. If you’re out at cricket, that is it for your day. With baseball, you’re engaged for a lot longer during the game.

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

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Paul Hawkins

Paul has more than 15 years of information security experience with a significant part of that working with financial services. He works across the range of AWS customers from start-ups to the largest enterprises to improve their security, risk, and compliance in the cloud.

AWS Security Profiles: CJ Moses, Deputy CISO and VP of Security Engineering

Post Syndicated from Supriya Anand original https://aws.amazon.com/blogs/security/aws-security-profiles-cj-moses-deputy-ciso-and-vp-of-security-engineering/

We recently sat down with CJ Moses, Deputy, Chief Information Security Officer (CISO), to learn about his day-to-day as a cybersecurity executive. He also shared more about his passion for racecar driving and why AWS is partnering with the SRO GT World Challenge America series this year.

How long have you been with AWS, and what is your role?

I’ve been with AWS since December 2007. I came to AWS from the FBI, along with current AWS CISO Steve Schmidt and VP/Distinguished Engineer Eric Brandwine. Together, we started the east coast AWS office. I’m now the Deputy CISO and VP of Security Engineering at AWS.

What excites you most about your role?

I like that every day brings something new and different. In the security space, it’s a bit of a cat and mouse game. It’s our job to be very much ahead of the adversaries. Continuing to engineer and innovate to keep our customers’ data secure allows us to do that. I also love providing customers things that didn’t exist in the past. The very first initiative that Steve, Eric and I worked on when we came from the government sector was Amazon Virtual Private Cloud (Amazon VPC), as well as the underlying network that gives customers virtually isolated network environments. By the end of 2011, the entire Amazon.com web fleet was running on this VPC infrastructure. Creating this kind of scalable offering and allowing our customers to use it was, as we like to say, making history.

We continue to work on new features and services that make it easier to operate more securely in the cloud than in on-premises datacenters. Over the past several years, we’ve launched services like Amazon GuardDuty (threat detection), Amazon Macie (sensitive data classification), and most recently AWS Security Hub (comprehensive security and compliance status monitoring). I love working for a company that’s committed to paying attention to customer feedback—and then innovating to not only meet those needs, but exceed them.

What’s the most challenging part of your role?

Juggling all the different aspects of it. I have responsibility for a lot of things, from auditing the physical security of our data centers to the type of hypervisor we need to use when thinking about new services and features. In the past, it was a Xen hypervisor based on open source software, but today AWS has built hardware and software components to eliminate the previous virtualization overhead. The Nitro system, as we call it, has had performance, availability, and security engineered into it from the earliest design phases, which is the right way to do it. Being able to go that full breadth of physical to virtual is challenging, but these challenges are what energize and drive me.

You’re an avid racecar driver. Tell us a bit about why you got into racing. What are the similarities between racecar driving and your job?

I got into racecar driving years ago, by accident. I bought an Audi A4 and it came with a membership to the Quattro club and they sent me a flyer for a track day, which is essentially a “take your streetcar to the track” event. I was hooked and began spending more and more time at the track. I’ve found that racecar drivers are extremely type A and very competitive. And because Amazon is very much a driven, fast-moving company, I think that what you need to have in place to succeed at Amazon is similar to what you need to be great on the racetrack. I like to tell my AWS team that they should be tactically impatient, yet strategically patient, and that applies to motorsports equally. You can’t win the race if you wreck in the first turn, but you also can’t win if you never get off the starting line.

Another similarity is the need to be laser-focused on the task at hand. In both environments, you need to be able to clear your mind of distractions and think from a new perspective. At AWS, our customer obsession drives what we do, the services and offerings we create, and our company culture. When I get in a racecar, there’s no time to think about anything except what’s at hand. When I’m streaming down the straightaway doing 180 mph, I need to focus on when to hit the brakes or when to make the next turn. When I get out of that car, I can then re-focus and bring new perspective to work and life.

AWS is the official cloud and machine learning provider of the SRO GT World Challenge America series this year. What drove the decision to become a partner?

We co-sponsored executive summits with our partner, CrowdStrike, at the SRO Motorsports race venues last year and are doing the same thing this year. But this year, we thought that it made sense to increase brand awareness and gain access to the GT Paddock Club for our guests. Paddock access allows you to see the cars up close and talk to drivers. It’s like a backstage pass at a concert.

In the paddock, every single car and team has sponsors or are self-funded—it’s like a small business-to-business environment. During our involvement last year, we didn’t see those businesses connecting with each other. What we hope to do this year is elevate the cybersecurity learning experience. We’re bringing in cybersecurity executives from across a range of companies to start dialogues with one another, with us, and with the companies represented in the paddock. The program is designed to build meaningful relationships and cultivate a shared learning experience on cybersecurity and AWS services in a setting where we can provide a once-in-a-lifetime experience for our guests. The cybersecurity industry is driven by trust-based relationships and genuinely being there for our customers. I believe our partnership with the SRO GT World Challenge series will provide a platform that helps us reinforce this.

What’s the connection between racecars and cloud security? How are AWS Security services being used at the racetrack?

With racing, there are tremendous workloads, such as telemetry and data acquisition, that you can stream from a car—essentially, hundreds of channels of data. There are advanced processing requirements for computational fluid dynamics, for example, both of air dynamics around the outside of the car and of air intake into and exhaust out of the engine. All these workloads and all this data are proprietary to the racing teams: The last thing you want is a competing racing team getting that data. This issue is analogous to data protection concerns amongst today’s traditional businesses. Also similar to traditional businesses, many racing teams need to be able to share data with each other in specific ways, to meet specific needs. For example, some teams might have multiple cars and drivers. Each of those drivers will need varying levels of access to data. AWS enables them to share that data in isolation, ensuring teams share only what’s needed. This kind of isolation would be difficult to achieve with a traditional data center or in many other environments.

AWS is also being used in new ways by GT World Challenge to help racecar drivers and partners make more real-time, data-driven decisions. For the first time, drivers and other racing partners will be able to securely stream telemetry directly to the AWS cloud. This will help drivers better analyze their driving and which parts of the course they need to improve upon. Crew chiefs and race engineers will have the data along with the advanced analytics to help them make informed decisions, such as telling drivers when it’s the most strategic time to make a pit stop.

This data will also help enhance the fan experience later this year. Spectators will be privy to some of the data being streamed through AWS and used by drivers, giving them a more intimate understanding of the velocity at which decisions need to be made on the track. We hope fans will be excited by this innovation.

What do you hope AWS customers will gain from attending GT World Challenge races?

I think the primary value is the opportunity to build relationships with experts and executives in the cybersecurity space, while enjoying the racetrack experience. We want to continue operating at the speed of innovation for our customers, and being able to build trust with them face-to-face helps enable this. We also keenly value the opportunity for customers to provide us feedback to influence how we think and what we offer at AWS, and I believe these events will provide opportunities where these conversations can easily take place.

In addition, we’ll be teasing out information about AWS re:Inforce (our upcoming security conference in Boston this June) at the GT Paddock Club. This includes information about the content, what to expect at the conference, and key dates. For anyone who wants to learn more about this event, I encourage them to visit https://reinforce.awsevents.com/, where you can read about our different session tracks, Steve Schmidt’s keynote, and other educational experiences we have planned.

How are you preparing for the races you’ll be in this year?

I’ve never raced professionally before, so driving the Audi R8 LMS GT4 this season has been a new experience for me. I’ve got my second race coming up this weekend (April 12th-14th), at the Pirelli GT4 Challenge at Long Beach, where AWS is the title sponsor. To prepare at home, I have a racing simulator that uses AWS services, as well as three large monitors, a steering wheel, pedals, and a moving and vibrating seat that I train on. I take what I learn from this simulation to the track in the actual car any chance I get. As the belated Jacob Levnon, a VP at AWS, was famous for saying, “There is no compression algorithm for experience.” I also do a lot of mental preparation by reading lap notes, watching videos of professional drivers, and working with my coaches. I’m grateful for the opportunity to be able to race this season and thank those that have helped me on this journey, both at AWS Security and on the racetrack.

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

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

AWS Security Profiles: Olivier Klein, Head of Emerging Technologies in the APAC region

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-olivier-klein-head-of-emerging-technologies-in-the-apac-region/

Leading up to AWS Summit Singapore, we’re sharing our conversation with keynote speaker Olivier Klein about his work with emerging technology and about the overlap between “emerging technology” and “cloud security.”

You’re the “Head of Emerging Technologies in the APAC region” on your team at AWS. What kind of work do you do?

I continuously explore new technologies. By “technologies”, I don’t only mean AWS services, but also technologies that exists in the wider market. My goal is to understand how these developments can help our customers chart the course of their own digital transformation. There’s a lot happening—including advances in AWS offerings. I’m seeing evolution in terms of core AWS compute, storage and database services all the way up to higher-level services such as AI, machine learning services, deep learning, augmented or virtual reality, and even cryptographically verifiable distributed data stores (such as blockchain). My role involves taking in all these various facets of “emerging technology” and answering the question: how do these innovations help our customers solve problems or improve their businesses? Then I work to provide best practices around which type of technology is best at solving which particular type of challenge.

Given the rapid pace of technological development, how do you keep track of what’s happening in the space?

My approach is two-fold. First, there’s the element of exploring new technologies and trying to wrap my own head around them to see how they can be useful. But I’m guided by the Amazon way of approaching a challenge: that is, I work backward from the customer. I try to closely monitor the types of challenges our customers are facing. Based on what I’ve seen first-hand, plus the feedback I’ve received from the rest of my team and from Solutions Architects out in the field on what customers are struggling with, I figure out which technologies would help address those pain points.

I’m a technologist; I get excited by technology. But I don’t believe in using new technologies just for the sake of using them. The technology should solve for a particular business outcome. For example, two of my recent areas of focus are artificial intelligence and machine learning. A lot of companies are either already using some form of machine learning or AI, or looking into it. But it’s not something you should do just for the sake of doing it. You need to figure out the specific business outcomes you want to achieve, and then decide which kinds of technology can help. Maybe machine learning is part of it. In the space of computer vision and natural language processing I’ve seen a lot of recent advancement that allows you to tackle new use cases and scenarios. But machine learning won’t always be the right kind of technology for you. So my primary focus is on helping customers makes sense of what types of tech they should be using to address specific scenarios and solve for specific business outcomes.

What’s your favorite part of your job?

It’s really exciting to see how technology can come to life and solve interesting problems at scale across many different industries, and for customer of all sizes, from startups to medium-sized businesses to large enterprises. They all face interesting challenges and it’s rewarding to be able to assist in that problem-solving process.

How would you describe the relationship between “emerging tech” and “cloud security”?
Security is a changing landscape. Earlier, I mentioned that machine learning and AI are an area of emerging tech that I focus on and that a lot of customers are getting on top of. I think similar trends are happening in the cloud security space. Traditionally, if you think of “security,” you probably think about physical boundaries, firewalls, and boxes that you need to protect. But when you move to the cloud, you have to rethink that model—the cloud offers all sorts of new capabilities. Take for example Amazon Macie, a service that allows you to use machine learning to understand data access patterns, to classify your data, to understand which data sets have personally identifiable information, and to potentially serve as a protection mechanism to ensure your data privacy.

More broadly, a cloud environment fundamentally changes what you’re able to do with security: Everything is programmable. Everything can be event-driven. Everything is code. An entire infrastructure can be put together as code. By this, I mean that you have the ability to detect and understand changes within your environment as they happen. You can have automated rules, automated account configurations, and machine learning algorithms that verify any kind of change. These systems can not only make your environment fully auditable, they can prevent changes as they’re happening, whether that’s a potential threat or an alteration to the environment that could carry security risk. Before this, securing your environment meant going through approvals, setting and configuring servers, routers and firewalls, and putting a lot of boundaries around them. That approach can work, but it doesn’t scale well, and it doesn’t always accommodate this new world where people want to experiment and be agile without compromising on security.

Security remains the most important consideration—but if you move to the cloud, you have a plethora of services that enable to you to create a controlled environment where any activity can immediately be checked against your security posture. Ultimately, this allows security professionals to become enablers. They can help people build effectively and securely, instead of the more traditional model of, “Here’s a list of all the things you can’t do.”

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

The cloud takes away the heavy lifting traditionally associated with security, and I’ve found that for some people, this is a difficult mental shift. AWS removes the entire problem of the physical boundaries and protections that you need to put in place to secure your servers and your data centers, and instead allows you to focus on securing and building applications.

Physical environments tend to foster a more reactive way of thinking about security. For example, you can log everything, and if something goes wrong, you can go back and check the logs to see what happened—but because there are so many manual interactions involved, it’s probably not a fast process. You’re always a little behind. AWS enables you to be much more proactive. For example, you might use AWS CloudTrail, which logs any kind of activity in your account against the entire AWS platform, and you might combine CloudTrail with AWS Config, which allows you to look at any configurational change within your environment and track it over a period of time. Combined, these services allow you to say, “If any change within my environment matches X set of rules, I want to be notified. If the change is compliant with the rules that I’ve set up, great—carry on. If it isn’t, I want to immediately revoke or remove the change, or maybe revoke the permissions or the credentials of the individual responsible for the change.” And we can give you a bunch of predefined rule sets that are ready to be compliant with certain scenarios, or you can build your own. Compare this to a physical data center: If someone goes and cuts a cable, how do you look into that? How long does it take? On AWS, any change can immediately be verified against your rule sets. You can immediately know what happened and can immediately and automatically take action. That’s a fundamental game changer for security—the ability to react as it happens. This difference is something that I really try to emphasize for our customers.

In your experience, how does the cloud adoption landscape differ between APAC and other markets?

In the Asia Pacific market, we have a lot of new companies starting to pop up and build against the entire global ecosystem, and against an entire global platform from their regions, which I think is really exciting. It’s a very fast-moving market. One of the key benefits of using AWS products and services is the tremendous agility that you get. You have the ability to build things fairly easily, create platforms and services at very large scale across multiple geographies, build them up, tear them down, and experiment with them using a plethora of services. I think in 2018, on average, we had three to five new capabilities made available to any developer—to any builder out there—every single day. That’s a fundamental game changer in the way you build systems. It’s really exciting to see what our customers are doing with all the new services and features.

What are some of the challenges—security or otherwise—that you see customers frequently face as they move to the cloud?

I think it comes back to that same challenge of showing customers that they don’t just need to take an existing model—whether their security infrastructure or anything else—and move it into a cloud environment without making any changes. You can do that, if you want. We provide you with many migration and integration services to do so effectively. But I really encourage customers to ask themselves, “How can I re-architect to optimize the benefits I’m getting from AWS for the specific use cases and applications I’m building?”

I believe that the true benefits of cloud computing come if you build in a way that’s either cloud-native or optimized for best practices. AWS allows you to build applications in a very agile, but also very lean manner. Look at concepts such as containerization, or even the idea of deploying applications that are completely serverless on top of AWS—you basically just deploy the code pieces for your application, we fully run and manage it, and you only pay for the execution time. Or look at storage or databases: traditionally, it might have made sense to put everything into a relational database. But if you want to build in a really agile, scalable, and cost-effective manner, that might not be the best option. And again, AWS provides you with so many choices: you can choose a database that allows you to look at relations, a database that allows you to run at hyper-growth scale across multiple geographies at the same time, a database for key value pair stores, graph-relation or timeseries focused databases, and so on. There are many different ways you can build on AWS to optimize for your particular use case. Initially it might be hard to wrap your head around this new way of building modern applications, but I believe that the benefits in terms of agility, cost effectiveness, and sheer possible hyperscale without headaches are worth it.

You’re one of the keynote speakers at the Singapore Summit. What are some themes you’ll be focusing on?

I’ll be speaking on the first day, which is what we call the Tech Fest. My keynote will primarily focus on the technology behind AWS products and services, and on how we build modern applications and modern data architectures. By that, I mean that we’ll take a look into what modern application architectures look like, how to effectively make use of data and how to build highly-scalable applications that are portable. In the Asia Pacific region, there’s a strong interest in mobile-first or web-first design. So how do we build effectively for those platforms? I’ll use my talk to look at some of the elements of distributed computing: how do you effectively build for a global, large-scale user base? How does distributed computing work? How do you use the appropriate AWS services and techniques to ensure that your last mile, even in remote areas, is done correctly?

I’ll also talk about the concept of data analytics and how to build effective data analysis on top of AWS to get meaningful insights, potentially in real-time. Beyond insights, we’ll have a look at using AI and machine learning to further create better customer experiences. Then I’ll wrap up with a look into robotics. We’ll have a variety of different interesting live demos across all of these topics.

What are you hoping that your audience will do differently as a result of your keynote?

One of the things I want people to take away is that, while there are numerous options for exactly how you build on AWS, there are some very common patterns for applying best practices. Don’t just build your applications and platforms in the old, traditional way of monolithic applications and physical blocks of services and firewalls. Instead, ask yourself, “How do I design modern-day application architectures? How do I make use of the information and data I’m collecting to build a better customer experience? How do I choose the best tools for my use case?” These are all things that we’ll talk about during the keynote. The workshops and bootcamps during the rest of the event are then designed to give you hands-on experience figuring out how to make use of various AWS services and techniques so that you can build in a cloud-native manner.

What else should visitors to Singapore take the time to do or see while they’re there?

I used to live in Singapore (although I currently live in Hong Kong). So if you’re visiting, one thing you should definitely check out is the hawker centers, which are the local food courts, and where you can try some great local delicacies. One of my personal favorites is a dish called bak kut teh. If you’re into an herbal soup experience, you should check it out. And if you’ve never been to Singapore, go to the Marina Bay, take a picture with the Merlion, which is the national symbol of Singapore, and enjoy the wonderful landscape and skyline.

You have an advanced certification with the Professional Association of Diving Instructors. Where is your favorite place to dive?

I live very close to some of the Southeast Asian seas, which have wonderful dive spots all over. It’s hard to pick a favorite. But one that stands out is a place called Sipadan. Sipadan was one of my most amazing dive experiences: I did one of those morning dives where you go out on the boat, the sun is just about to come up, you jump into the sea, and the entire marine world wakes up. It’s a natural marine park, so even if you don’t scuba dive and just snorkel, there’s probably no place you can go to see more fish, and sharks, and turtles.

If you’ve never tried scuba diving, I’d recommend it. Snorkeling is great, but scuba diving gives you a fundamentally different experience. It’s much more calming. While snorkeling, you hear your breathing as you swim around. But if you scuba dive, and you’ve got good control of your buoyancy, you can just hover in the water and quietly watch aquatic life pass around you. With quiet like that, marine life is less afraid and approaches you more easily.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author photo

Olivier Klein

Olivier is a hands-on technologist with more than 10 years of experience in the industry and has been working for AWS across APAC and Europe to help customers build resilient, scalable, secure and cost-effective applications and create innovative and data driven business models.

AWS Security Profiles: Nathan Case, Senior Security Specialist, Solutions Architect

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-nathan-case-senior-security-specialist-solutions-architect/

AWS Security Profiles: Nathan Case, Senior Security Specialist, Solutions Architect

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.

Author photo

Nathan Case

Nathan is a Senior Security Specialist, Solutions Architect. He joined AWS in 2016.

AWS Security Profiles: Akihiro Umegai, Japan Lead, Office of the CISO

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-akihiro-umegai-japan-lead-office-of-the-ciso/


In the weeks leading up to the Solution Days event in Tokyo, 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 with AWS, and what is your role?

I’ve been at AWS for six and a half years. I’m the Japanese representative for the Office of the CISO, a team that’s led by Mark Ryland . We play a supporting role for Steve Schmidt, the Chief Information Security Officer for all of AWS. I help with external-facing functions as well as handling some internal cloud security mitigation tasks.

What are some differences between your role as Japanese representative for the CISO versus what your US counterparts do?

When US companies want to do business in Japan, they face a language and cultural barrier. Perhaps as many as 95% of Japanese companies don’t fully utilize English, which makes it hard to effectively communicate with most US companies. Japan also has traditional business systems and cultural ways of doing things that can seem very unique to outsiders. We put a lot of emphasis on communication and trust-building. Those might be the two most unique elements of doing business in Japan.

There are challenges, but the market size is potentially huge. I tell people that I function as the shock absorber, or stabilizer, between Japan and US headquarters. I interpret the directions of the AWS US team, adapt them to the Japanese market, and then communicate with our Japanese customers.

What’s the most challenging part of your job?

At a certain level, the Japanese market tends to follow the trends of the US market. For example, in Japan, there is a similar need to have Chief Information Security Officers: people who makes decisions about comprehensive security issues on behalf of their companies. However, the concept of a CISO is just beginning to take hold, and CISOs might not be fully considered a primary part of corporate C-level functions. I feel that we need to support our customers’ security leaders in order to help them solidify their security posture.

Historically, Japanese companies have also outsourced many of their IT functions, with Japanese local system integrators supporting these processes. Our customers often need to work with their partners to make decisions, including decisions about security operations and even some compliance matters. It’s critical to involve these local partners, who are very familiar with Japanese customs and business. When I create a security and compliance reference document for any guidelines in the Japanese market, I always form a partner group with three to six partners who know the specific domains in their particular market. Our combined effort allows us to produce practical, customer-centric solutions. These types of partnerships also help us get remarkable attention from the Japanese market: “Big, local, and traditional Japanese system integrators are working with the US cloud vendor AWS!” That process of developing great relationships with partners is the tough part of my job. I might spend 30 – 40 percent of my time in direct customer communication, and 60 – 70 percent of my time communicating with partners.

What are some of the broad differences between global and Japanese markets with respect to the cloud?

As one example, in the financial arena, Japanese regulators are very serious and tough. The main regulator is the Financial Service Agency — the FSA — which controls the issuance of bank licenses. It’s hard to get those licenses in the Japanese market. In contrast, bank regulators in the EU have already issued a license for “challenger banks” that primarily utilize cloud environments for their systems. The total cost of establishing this type of “cloud-based” bank is significantly lower than establishing a traditional on-premise, mainframe-based banking system. It’s a remarkable use case for Japanese regulators and customers. Such new, cloud-based systems usually employ “ready-made” banking system middleware, which is already configured to serve banks’ main functions — customers can purchase the middleware, put it on AWS, and then start a bank within a short period of time. The US-based bank Capital One is another interesting use case: they represent an “all-in” approach of moving all their workloads from an on-premise environment to AWS. You can read the case study here.

However, I do not mean Japanese regulators or banks are behind. They are very rigorous about following rules, and they are very diligent about keeping the trust of their customers. They’re handling the adoption of new technology with care and precision, and they’re interested in listening. In fact, Japanese regulators and related entities, like the FSA, the BOJ (Bank of Japan), and the FISC (Center for Financial Industry Information Systems) are keen to learn good practice from global case studies and new technology use cases in order to enhance Japanese financial business. I’m always looking for interesting, attractive use cases from outside to openly share with them.

What’s the most common misperception you encounter about cloud security and compliance?

Some customers assume that they still need to perform physical data center audits, even if there is no clear objective to visiting the data center. When customers ask me about physical data center audits, I always encourage them to leverage our third-party audit reports (like our SOC-2 reports) and refer to our digital tour of an AWS data center to get a sense of how AWS operate. However, I think risk residing in physical data centers is just one part of the entire process of risk control, and other, more important controls must be emphasized. For example: How will you detect and catch unauthorized access? How will you process detailed logs from various sources? Can you automate security operation by utilizing new, cloud-based security functions to reduce human-based operational risk? Part of the challenge is that AWS needs to translate more of our audit reports (something that is partially my duty). It’s difficult for Japanese customers to interpret a SOC-2 report in English when even native English speakers might have difficulty with the extremely detailed security language. Better translations would directly help us do a better job of explaining these concepts to our customers.

Another common misunderstanding stems from how to perform system audits in a cloud environment. Most existing audits are like a sample base. You can’t read through every log or piece of evidence like a book. For example, auditors might check page 10, skip to page 30, finish sampling, and end the audit. There are “not-yet-checked” portions of the accumulated logs that could have potential residual risk, which is skipped. But in a cloud system, we can gather every detailed log. Most AWS service functions produce lots of detail, and we can process the logs either with Amazon GuardDuty, or machine learning, or third-party log consolidation tools. Ultimately, we’re able to perform a much more detailed, accurate audit — and many customers miss this fact. There’s a gap between what the “compliance audit guy” knows and what the cloud security engineer knows. Compliance professionals don’t always have a deep understanding of technology. They don’t always know how to gather logs from cloud-based systems. But security engineers do. We need to connect these people and go through how to perform audits in cloud systems in a more effective, holistic way to truly secure systems and reduce risk.

What’s your favorite part of your job?

Disruption via new concepts and offerings. Let me give you an example: The Center for Financial Industry Information Systems (FISC) develops and publishes general system security guidelines for financial institutions in Japan. Five years ago, when I called on regulators or regulated customers, they’d all ask me, “What is cloud? How is it different from on-premise? The regulations don’t have any mention of cloud, so we aren’t sure how it could be utilized under the current guidelines.” Customers didn’t know what sort of reaction they’d get from regulators if they moved to the cloud. But over the past five or six years, I’ve shared our security practices and knowledge step-by-step — what’s going on in the US and global markets, which big customers have started using AWS for regulated workloads, and so on. And regulated customers have come to understand that the cloud is a more efficient way to achieve their security compliance. I share market information and techniques that regulated customers can use to think about cloud security controls. Regulators and regulated customers have started to slowly change their perception and become more accepting of the AWS concept of security and compliance. For the last two years, I’ve actually been an official member of some of the expert councils at FISC. Helping to change peoples’ perceptions like that is exciting!

What do you hope your audience will gain from attending AWS Solution Days?

Our goal is to share how AWS can help customers get one step ahead in the fields of cloud security and compliance. We recently announced two major security services, AWS Security Hub and AWS Control Tower, and I hope Japanese customers will see how they can use these services to continue improving their security posture. In addition, the Japanese government has recently become interested in changing their policy for employing the cloud for government systems. They have a lot of interest in how cloud is used in the US. One of the goals of AWS Solution Days is to share what’s going on in US government systems. It should be equally interesting to people in the commercial sector, in terms of learning how high-security systems are being achieved in AWS environments.

What should first-time travelers to Tokyo do or experience?

When you visit Japan, I would suggest trying new foods, especially if you like sushi. The sushi bars have fish that is fresh and super high quality, so order something new off the menu, even if you think you might not like it. It could disrupt your perception of seafood! You might leave with a new appreciation!

Also, American people are sometimes surprised to find that Japan is a very westernized country, although it still retains its own very unique culture. You’ll see McDonalds, Starbucks, lots of US-based companies. There’s lots of American culture, in fact, but it’s all modified by Japanese language and culture, resulting in a new, interesting experience.

You are a DJ: What’s a recently released album that you’d recommend?

I really like club music, like techno and American heavy metal. In addition to being a DJ, I sometimes play the electric guitar. So I would instead recommend one old song which changed my life and turned me from a heavy metal guitar kid into a synthesizer geek. The band is Orbital, and on their 1992 album “Diversions,” there is a song called “Impact USA” that’s my all-time favorite. It’s a beautiful track — it has beautiful melodies and an atmosphere that I think make it universally appealing, even if you don’t typically like techno.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.


Akihiro Umegai

Akihiro joined AWS in 2012 and currently serves as the Japan lead for the Office of the CISO – AWS Security. In this role, he engages with CISOs, CIOs, and government regulators to address their security and regulatory compliance requirements. He’s also a committee member and contributor for Japan’s Center for Financial Industry Information Systems (FISC), where he provides input on the security controls.

AWS Security profiles: Michael South, Principal Business Development Manager for Security Acceleration

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-michael-south-principal-business-development-manager-for-security-acceleration/


In the weeks leading up to the Solution Days event in Tokyo, 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 since August 2017. I’m part of a team called SeCBAT — the Security and Compliance Business Acceleration Team. I lead customer-focused executive security and compliance efforts for the public sector in the Americas, from Canada down to Chile, and spanning federal government, defense, state and local government, education, and non-profit verticals. The team was established in 2017 to address a need we saw in supporting our customers. While we have fantastic solution architects who connect easily with our customers’ architects and engineers, we didn’t have a readily available team in our World Wide Public Sector organization to engage customers interested in security at the executive level. When we worked with people like CISOs — Chief Information Security Officers — there was a communication gap. CISOs have a broader scope than engineers, and are oftentimes not as technically deep. Technology is only one piece of the puzzle that they’re trying to solve. Other challenging pieces include policy, strategy, culture shift, staffing and training, and the politics of their entire organization. SeCBAT is comprised of prior government CISOs (or similar roles), allowing us to establish trust quickly. We’ve been in their shoes, so we understand the scope of their concerns, we can walk them through how they can meet their security and compliance objectives in AWS, and we can help remove barriers to cloud adoption for the overall customer.

These customer engagements are one of my primary functions. The team also spends a lot of time on strategic communications: presenting at conferences and tradeshows, writing whitepapers and blogs, and generally providing thought leadership for cloud security. Lastly, we work closely with Amazon Public Policy as subject matter experts to assist in reviewing and commenting on draft legislation and government policies, and in meetings with legislators, regulators, and policy-makers to educate them on how security in the cloud works so they can make informed decisions.

What’s the most challenging part of your job?

Customers who are new to the cloud often grapple with feelings of fear and uncertainty (just like I did). For me, figuring out how to address that feeling is a challenge that varies from person to person. It isn’t necessarily based on facts or data — it’s a general human reaction to something new. “The cloud” is very mysterious to people who are just coming into it, and oftentimes their sources of information are inaccurate or sensationalized news articles, combined with a general overuse of the word “cloud” in marketing materials from traditional vendors who are trying to cash in on this industry shift. Once you learn what the cloud really is and how it works, what’s the same and what’s different than what you’re used to on-prem, you can figure out how to manage it, secure it, and incorporate it into your overall strategy. But trying to get past that initial fear of the unknown is challenging. Part of what I do is educate people and then challenge some of the assumptions they might have made prior to our meeting. I want people to be able to look at the data so that they can make an informed decision and not lose an opportunity over a baseless emotion. If they choose not to go to the cloud, then that is absolutely fine, but at least that decision is made on facts and what’s best for the organization.

What’s the most common misperception you encounter about cloud security and compliance?

Visibility. There’s a big misperception that customers will lose visibility into their data and their systems in the cloud, and this becomes a root cause of many other misconceptions. It’s usually the very first point that I focus on in my briefs and discussions. I walk customers through my cloud journey, including my background in traditional security in an on-prem environment. As the Deputy CISO for the city of Washington, DC, I was initially very nervous about transitioning to the cloud, but I tasked my team and myself to dive deep and learn. It didn’t take long for us to determine that not only could we be just as secure and compliant in the cloud as on-prem, but that we could achieve a greater level of security and compliance through resiliency, continuous monitoring, and automated security operations. During our research, we also had to deal with a few on-prem issues, and that’s when it dawned on me that the cloud gave me something that I’d been lacking for my entire IT career — essentially 100% visibility! It didn’t matter if a server was on or off, what network segment it was on, whether the endpoint agent was installed or reporting up, or any other state — I had absolute visibility into every asset we had in the cloud. From here, we could secure and automate with much greater confidence, which resulted in fewer “fires” to put out. Security ended up being a driving force behind the city’s cloud adoption strategy. The security and governance journey can take a while at first, but these factors will enable everyone else move fast, safely. The very first step is understanding the visibility that the cloud allows.

You’ll be giving a keynote at AWS Solution Days, in Tokyo. Is this the first time you’ve been to Japan?

No, my family and I were very fortunate to have lived in Yokosuka, Japan for a few years. I served in the U.S. Navy for 25 years prior to joining AWS, where I enjoyed two tours in Japan. The first was as the Seventh Fleet Information Assurance Manager, the lead for cybersecurity for all U.S. Naval forces in Asia. The second was as the Navy Chief Information Officer (CIO) for all U.S. Naval forces in Japan. Those experiences were some of the best of my career and family life. We would move back to Japan in a heartbeat!

The keynote is called “U.S. government and U.S. defense-related security.” What implications do U.S. government and defense policies have for AWS customers in Japan?

The U.S. and Japan are very strong political and military allies. Their governments and militaries share common interests and defense strategies, and collaborate on a myriad of socio-economic topics. This all requires the sharing of sensitive information, which is where having a common lexicon, standards, and processes for security benefit both parties. I plan to discuss the U.S. environment and highlight things that are working well in the U.S. that Japan might want to consider adopting, plus some things that might not be a good fit—coupled with recommendations on what might be better opportunities. I also plan to demonstrate that AWS is able to meet the high standards of the U.S. government and military with very strict, regulated security. I hope that this will give Japanese customers confidence in our ability to meet the similarly rigorous requirements they might have.

In your experience, how does the cloud security landscape differ between US and Japanese markets?

From my understanding, the Japanese government is in the very early stages of cloud adoption. Many ministries are assessing how they might use the cloud and secure their sensitive data in it. In addition to speaking at the summit, one of my reasons for visiting Japan is to meet with Japanese government customers to learn about their efforts. They’re very much interested in what the U.S. government is doing with AWS. They would like to leverage lessons learned, technical successes, and processes that are working well, in addition to learning about things that they might want to do differently. It’s a great opportunity to showcase all the work we’re doing with the U.S. government that could also benefit the Japanese government.

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

My hope is that we’ll see a better, more holistic method of implementing governance with security engineering and security operations. Right now, globally across the cybersecurity landscape, there are silos: development security, governance, compliance, risk management, engineering, security operations, etc. They should be more mutually supportive and interconnected, and as you implement a plan in one area, it should go into effect seamlessly across the other areas.

Similarly, my hope is that five years from now we’ll start seeing a merge between the technologies and people and processes. Right now, the cybersecurity industry seems to try to tackle every problem with a technological solution. But technology is really the easiest part of every problem. The people and the processes are much more difficult. I think we need to devote a lot more time toward developing a holistic view of cybersecurity based on business risk and objectives.

Why should emerging markets move to the cloud now? Why not wait another five years in the hope that the technology will mature?

I’d like to challenge the assumption that the cloud is not mature. At least with AWS and our near competitors, I’d say the cloud is very mature and provides a level of sophistication that is very difficult and costly to replicate on-prem. If the concern is about technical maturity, you’re already late.

In addition, the waiting approach poses two problems: First, if you’re not engaged now in learning how the cloud works, you’ll just be further behind the curve in five years. Second, I see (and believe I’ll continue to see) that the vast majority of new technologies, services, and concepts are being born in the cloud. Everything is hyper-converging on the cloud as the foundational platform for all other emerging technologies. If you want to be successful with the next big idea in five years, it’s better to get into the cloud now and become an expert at what it can do—so that you’re ready for that next big idea. Because in some way, shape, or form, it’s going to be in or enabled by the cloud.

What are your favorite things to do when you’re visiting Japan?

The history and tradition of Kyoto makes it my favorite city in Japan. But since we’ll be in Tokyo, there a few things there that I’d recommend. First, the 100-Yen sushi-go-rounds. To Americans, I’d explain it as paying one US dollar for a small plate (2 pieces of nigiri or 4 roll slices) of fantastic sushi. You can eat thirty plates for thirty bucks! Places in Tokyo to visit are Harajuku for people-watching, with all the costumes and fashion, Shibuya for shopping, and of course Tokyo tower. I also recommend Ueno park, somewhat close to where our event will be held, which has a pond and zoo.

Japan is one of the safest and politest countries I’ve been to — and I’ve visited about 40 at this point. The people I’ve met there have all been extraordinarily nice and are what really makes Japan so special. I’d highly recommend visiting.

What’s your favorite thing to do in your hometown?

I’m originally from Denver, Colorado. If you’re in Denver, you’ve got to go up to the mountains. If you’re there in the summer, you can hike, camp, go white-water rafting, or horseback riding. If you’re there in the winter, you can go skiing or snowboarding, or just sit by the fire with a hot toddy. It really doesn’t matter. Just go up to the mountains and enjoy the beautiful scenery and wildlife.

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.

Michael South

Michael joined AWS in 2017 as the Americas Regional Leader for public sector security and compliance business development. He supports customers who want to achieve business objectives and improve their security and compliance in the cloud. His customers span across the public sector, including: federal governments, militaries, state/provincial governments, academic institutions, and non-profits from North to South America. Prior to AWS, Michael was the Deputy Chief Information Security Officer for the city of Washington, DC and the U.S. Navy’s Chief Information Officer for Japan.

AWS Security Profile (and re:Invent 2018 wrap-up): Eric Docktor, VP of AWS Cryptography

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profile-and-reinvent-2018-wrap-up-eric-docktor-vp-of-aws-cryptography/

Eric Docktor

We sat down with Eric Docktor to learn more about his 19-year career at Amazon, what’s new with cryptography, and to get his take on this year’s re:Invent conference. (Need a re:Invent recap? Check out this post by AWS CISO Steve Schmidt.)

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

I’ve been at Amazon for over nineteen years, but I joined AWS in April 2015. I’m the VP of AWS Cryptography, and I lead a set of teams that develops services related to encryption and cryptography. We own three services and a tool kit: AWS Key Management Service (AWS KMS), AWS CloudHSM, AWS Certificate Manager, plus the AWS Encryption SDK that we produce for our customers.

Our mission is to help people get encryption right. Encryption algorithms themselves are open source, and generally pretty well understood. But just implementing encryption isn’t enough to meet security standards. For instance, it’s great to encrypt data before you write it to disk, but where are you going to store the encryption key? In the real world, developers join and leave teams all the time, and new applications will need access to your data—so how do you make a key available to those who really need it, without worrying about someone walking away with it?

We build tools that help our customers navigate this process, whether we’re helping them secure the encryption keys that they use in the algorithms or the certificates that they use in asymmetric cryptography.

What did AWS Cryptography launch at re:Invent?

We’re really excited about the launch of KMS custom key store. We’ve received very positive feedback about how KMS makes it easy for people to control access to encryption keys. KMS lets you set up IAM policies that give developers or applications the ability to use a key to encrypt or decrypt, and you can also write policies which specify that a particular application—like an Amazon EMR job running in a given account—is allowed to use the encryption key to decrypt data. This makes it really easy to encrypt data without worrying about writing massive decrypt jobs if you want to perform analytics later.

But, some customers have told us that for regulatory or compliance reasons, they need encryption keys stored in single-tenant hardware security modules (HSMs) that they manage. This is where the new KMS custom key store feature comes in. Custom key store combines the ease of using KMS with the ability to run your own CloudHSM cluster to store your keys. You can create a CloudHSM cluster and link it to KMS. After setting that up, any time you want to generate a new master key, you can choose to have it generated and stored in your CloudHSM cluster instead of using a KMS multi-tenant HSM. The keys are stored in an HSM under your control, and they never leave that HSM. You can reference the key by its Amazon Resource Name (ARN), which allows it to be shared with users and applications, but KMS will handle the integration with your CloudHSM cluster so that all crypto operations stay in your single-tenant HSM.

You can read our blog post about custom key store for more details.

If both AWS KMS and AWS CloudHSM allow customers to store encryption keys, what’s the difference between the services?

Well, at a high level, sure, both services offer customers a high level of security when it comes to storing encryption keys in FIPS 140-2 validated hardware security modules. But there are some important differences, so we offer both services to allow customers to select the right tool for their workloads.

AWS KMS is a multi-tenant, managed service that allows you to use and manage encryption keys. It is integrated with over 50 AWS services, so you can use familiar APIs and IAM policies to manage your encryption keys, and you can allow them to be used in applications and by members of your organization. AWS CloudHSM provides a dedicated, FIPS 140-2 Level 3 HSM under your exclusive control, directly in your Amazon Virtual Private Cloud (VPC). You control the HSM, but it’s up to you to build the availability and durability you get out of the box with KMS. You also have to manage permissions for users and applications.

Other than helping customers store encryption keys, what else does the AWS Cryptography team do?

You can use CloudHSM for all sorts of cryptographic operations, not just key management. But we definitely do more than KMS and CloudHSM!

AWS Certificate Manager (ACM) is another offering from the cryptography team that’s popular with customers, who use it to generate and renew TLS certificates. Once you’ve got your certificate and you’ve told us where you want it deployed, we take care of renewing it and binding the new certificate for you. Earlier this year, we extended ACM to support private certificates as well, with the launch of ACM Private Certificate Authority.

We also helped the AWS IoT team launch support for cryptographically signing software updates sent to IoT devices. For IoT devices, and for software installation in general, it’s a best practice to only accept software updates from known publishers, and to validate that the new software has been correctly signed by the publisher before installing. We think all IoT devices should require software updates to be signed, so we’ve made this really easy for AWS IoT customers to implement.

What’s the most challenging part of your job?

We’ve built a suite of tools to help customers manage encryption, and we’re thrilled to see so many customers using services like AWS KMS to secure their data. But when I sit down with customers, especially large customers looking seriously at moving from on-premises systems to AWS, I often learn that they have years and years of investment into their on-prem security systems. Migrating to the cloud isn’t easy. It forces them to think differently about their security models. Helping customers think this through and map a strategy can be challenging, but it leads to innovation—for our customers, and for us. For instance, the idea for KMS custom key store actually came out of a conversation with a customer!

What’s your favorite part of your job?

Ironically, I think it’s the same thing! Working with customers on how they can securely migrate and manage their data in AWS can be challenging, but it’s really rewarding once the customer starts building momentum. One of my favorite moments of my AWS career was when Goldman Sachs went on stage at re:Invent last year and talked about how they use KMS to secure their data.

Five years from now, what changes do you think we’ll see within the field of encryption?

The cryptography community is in the early stages of developing a new cryptographic algorithm that will underpin encryption for data moving across the internet. The current standard is RSA, and it’s widely used. That little padlock you see in your web browser telling you that your connection is secure uses the RSA algorithm to set up an encrypted connection between the website and your browser. But, like all good things, RSA’s time may be coming to an end—the quantum computer could be its undoing. It’s not yet certain that quantum computers will ever achieve the scale and performance necessary for practical applications, but if one did, it could be used to attack the RSA algorithm. So cryptographers are preparing for this. Last year, the National Institute of Standards and Technology (NIST) put out a call for algorithms that might be able to replace RSA, and got 68 responses. NIST is working through those ideas now and will likely select a smaller number of algorithms for further study. AWS participated in two of those submissions and we’re keeping a close eye on NIST’s process. New cryptographic algorithms take years of testing and vetting before they make it into any standards, but we want to be ready, and we want to be on the forefront. Internally, we’re already considering what it would look like to make this change. We believe it’s our job to look around corners and prepare for changes like this, so our customers don’t have to.

What’s the most common misconception you encounter about encryption?

Encryption technology itself is decades-old and fairly well understood. That’s both the beauty and the curse of encryption standards: By the time anything becomes a standard, there are years and years of research and proof points into the stability and the security of the algorithm. But just because you have a really good encryption algorithm that takes an encryption key and a piece of data you want to secure and spits out an impenetrable cipher text, it doesn’t mean that you’re done. What did you do with the encryption key? Did you check it into source code? Did you write it on a piece of paper and leave it in the conference room? It’s these practices around the encryption that can be difficult to navigate.

Security-conscious customers know they need to encrypt sensitive data before writing it to disk. But, if you want your application to run smoothly, sometimes you need that data in clear text. Maybe you need the data in a cache. But who has access to the cache? And what logging might have accidentally leaked that information while the application was running and interacting with the cache?

Or take TLS certificates. Each TLS certificate has a public piece—the certificate—and a private piece—a private key. If an adversary got ahold of the private key, they could use it to impersonate your website or your API. So, how do you secure that key after you’ve procured the certificate?

It’s practices like this that some customers still struggle with. You have to think about all the places that your sensitive data is moving, and about real-world realities, like the fact that the data has to be unecrypted somewhere. That’s where AWS can help with the tooling.

Which re:Invent session videos would you recommend for someone interested in learning more about encryption?

Ken Beer’s encryption talk is a very popular session that I recommend to people year after year. If you want to learn more about KMS custom key store, you should also check out the video from the LaunchPad event, where we talked with Box about how they’re using custom key store.

People do a lot of networking during re:Invent. Any tips for maintaining those connections after everyone’s gone home?

Some of the people that I meet at re:Invent I get to see again every year. With these customers, I tend to stay in touch through email, and through Executive Briefing Center sessions. That contact is important since it lets us bounce ideas off each other and we use that feedback to refine AWS offerings. One conference I went to also created a Slack channel for attendees—and all the attendees are still on it. It’s quiet most of the time, but people have a way to re-engage with each other and ask a question, and it’ll be just like we’re all together again.

If you had to pick any other job, what would you want to do with your life?

If I could do anything, I’d be a backcountry ski guide. Now, I’m not a good enough skier to actually have this job! But I like being outside, in the mountains. If there was a way to make a living out of that, I would!

Author photo

Erick Docktor

Eric joined Amazon in 1999 and has worked in a variety of Amazon’s businesses, including being part of the teams that launched Amazon Marketplace, Amazon Prime, the first Kindle, and Fire Phone. Eric has also worked in Supply Chain planning systems and in Ordering. Since 2015, Eric has led the AWS Cryptography team that builds tools to make it easy for AWS customers to encrypt their data in AWS. Prior to Amazon, Eric was a journalist and worked for newspapers including the Oakland Tribune and the Doylestown (PA) Intelligencer.

AWS Security Profiles: Quint Van Deman, Principal Business Development Manager

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-quint-van-deman-principal-business-development-manager/

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?

I joined AWS in August 2014. I spent my first two and a half years in the Professional Services group, where I ran around the world to help some of our largest customers sort through their security and identity implementations. For the last two years, I’ve parleyed that experience into my current role of Business Development Manager for the Identity and Directory Services group. I help the product development team build services and features that address the needs I’ve seen in our customer base. We’re working on a next generation of features that we think will radically simplify the way customers implement and manage identities and permissions within the cloud environment. The other key element of my job is to find and disseminate the most innovative solutions I’m seeing today across the broadest possible set of AWS customers to help them be more successful faster.

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

I keep one foot in the AWS service team organizations, where they build features, and one foot in day-to-day customer engagement to understand the real-world experiences of people using AWS. I learn about the similarities and differences between how these two groups operate, and then I help service teams understand these similarities and differences, as well.

You’re a “bar raiser” for the Security Blog. What does that role entail?

The notion of being a bar raiser has a lot of different facets at Amazon. The general concept is that, as we go about certain activities — whether hiring new employees or preparing blog posts — we send things past an outside party with no team biases. As a bar raiser for the Security Blog, I don’t have a lot of incentive to get posts out because of a deadline. My role is to make sure that nothing is published until it successfully addresses a customer need. At Amazon, we put the best customer experience first. As a bar raiser, I work to hold that line, even though it might not be the fastest approach, or the path of least resistance.

What’s the most challenging part of your job?

Ruthless prioritization. One of our leadership principles at Amazon is frugality. Sometimes, that means staying in cheap hotel rooms, but more often it means frugality of resources. In my case, I’ve been given the awesome charter to serve as the Business Development Manager for our suite of Identity and Directory Services. I’m something of a one-man army the world over. But that means a lot of things come past my desk, and I have to prioritize ruthlessly to ensure I’m focusing on the things that will be most impactful for our customers.

What’s your favorite part of your job?

A lot of our customers are doing an awesome job being bar raisers themselves. They’re pushing the envelope in terms of identity-focused solutions in their own AWS environments. One fulfilling part of my work is getting to collaborate with those customers who are on the leading edge: Their AWS field teams will get ahold of me, and then I get to do two really fun things. First, I get to dive in and help these customers succeed at whatever they’re trying to do. Second, I get to learn from them. I get to examine the really amazing ideas they’ve come up with and see if we might be able to generalize their solutions and roll them out to the delight of many more AWS customers that might not have teams mature enough to build them on their own. While my title is Business Development Manager, I’m a technologist through and through. Getting to dive into these thorny technical situations and see them resolve into really great solutions is extremely rewarding.

How did you choose your particular topics for re:Invent 2018?

Over the last year, I’ve talked with lots of customers and AWS field teams. My Mastering Identity at Every Layer of the Cake session was born out of the fact that I noticed a lot of folks doing a lot of work to get identity for AWS right, but other layers of identity that are just as important weren’t getting as much attention. I made it my mission to provide a more holistic understanding of what identity in the cloud means to these customers, and over time I developed ways of articulating the topic which really seemed to resonate. My session is about sharing this understanding more broadly. It’s a 400-level talk, since I want to really dive deep with my audience. I have five embedded demos, all of which are going to show how to combine multiple features, sprinkle in a bit of code, and apply them to near universally applicable customer use cases.

Why use the metaphor of a layer cake?

I’ve found that analogies and metaphors are very effective ways of grounding someone’s mental imagery when you’re trying to relay a complex topic. Last year, my metaphor was bridges. This year, I decided to go with cake: It’s actually very descriptive of the way that our customers need to think about Identity in AWS since there are multiple layers. (Also, who doesn’t like cake? It’s delicious.)

What are you hoping that your audience will take away from the session?

Customers are spending a lot of time getting identity right at the AWS layer. And that’s a ground-level, must-do task. I’m going to put a few new patterns in the audience’s hands to do this more effectively. But as a whole, we aren’t consistently putting as much effort into the infrastructure and application layers. That’s what I’m really hoping to expose people to. We have a wealth of features that really raise the bar in terms of cloud security and identity — from how users authenticate to operating systems or databases, to how they authenticate to the applications and APIs that they put on AWS. I want to expose these capabilities to folks and paint a vivid image for them of the really powerful things that they can do today that they couldn’t have done before.

What do you want your audience to do differently after attending your session?

During the session, I’ll be taking a handful of features that are really interesting in their own right, and combining them in a way that I hope will absolutely delight my audience. For example, I’ll show how you can take AWS CloudFormation macros and AWS Identity and Access Management, layer a little bit of customization on top, and come up with something far more magical than either of the two individually. It’s an advanced use case that, with very little effort, can disproportionately improve your security posture while letting your organization move faster. That’s just one example though, and the session is going to be loaded with them, including a grand finale. I’ve already started the work to open source a lot of what I’m going to show, but even where I can’t open source, I want to paint a very clear, prescriptive blueprint for how to get there. My goal is that my audience goes back to work on Monday and, within a couple of hours, they’ve measurably moved the security bar for their organization.

Any tips for first-time conference attendees?

Be deliberate about going outside of your comfort zone. If you’re not working in Security, come to one of our sessions. If you do work in Security, go to some other tracks, like Dev-Ops or Analytics, to get that cross-pollination of ideas. One of the most amazing things about AWS is how it helps dramatically lower the barrier to entry for unfamiliar technology domains and tools. A developer can ship more secure code faster by being invested in security, and a security expert can disproportionally scale their impact by applying the tools of developers or data scientists. Re:Invent is an amazing place to start exploring that diversity, and if you do, I suspect you’ll find ways to immediately make yourself better at your day job.

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

Complexity versus human understanding have always been at odds. I see initiatives across AWS that have all kinds of awesome innovation and computer science behind them. In the coming years, I think these will mature to the point that they will be able to offload much of the natural complexity that comes with securing large scale environments with extremely fine grain permissions. Folks will be able to provide very simple statements or rules of how they want their environment to be, and we should be able to manage the complexity for them, and present them with a nice, clean picture they can easily understand.

What does cloud security mean to you, personally?

I see possibilities today that were herculean tasks before. For example, the process to make sure APIs can properly authenticate and authorize each other used to be an extremely elaborate process at scale. It became such an impossible mess that only the largest of organizations with the best skills, the best technology, and the best automation were really able to achieve it. Everyone else just had to punt or put a band-aid on the problem. But in the world of the cloud, all it takes is attaching an AWS IAM role on one side, and a fairly small resource-based policy to an Amazon API Gateway API on the other. Examples like this show how we’re making security that would once have been extremely difficult for most customers to afford or implement simple to configure, get right, and deploy ubiquitously, and that’s really powerful. It’s what keeps me passionate about my work.

If you had to pick any other job, what would you want to do with your life?

I’ve got all kinds of whacky hobbies. I kiteboard, I surf, work on massive renovation projects at home, hike and camp in the backcountry, and fly small airplanes. It’s an overwhelming set of hobbies that didn’t align with my professional aptitude. But if the world were my oyster and I had to do something else, I would want to combine those hobbies into one single career that’s never before been seen.

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.


Quint Van Deman

Quint is the global business development manager for AWS Identity and Directory services. In this role, he leads the incubation, scaling, and evolution of new and existing identity-based services, as well as field enablement and strategic customer advisement for the same. Before joining the BD team, Quint was an early member of the AWS Professional Services team, where he was a Senior Consultant leading cloud transformation teams at several prominent enterprise customers, and a company-wide subject matter expert on IAM and Identity federation.

AWS Security Profiles: Henrik Johansson, Principal, Office of the CISO

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-henrik-johansson-principal-office-of-the-ciso/

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?

As a Principal for the Office of the CISO, I not only get to spend time directly with our customers and their executives and operational teams, I also get to work with our own service teams and other parts of our organization. Additionally, a big part of this role involves spending time with the industry as a whole, in both small and large settings, and trying to raise the bar of the overall industry together with a number of other teams within AWS.

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

Whether or not someone understands what the cloud is, I try to focus on the core part of the role: I help people and organizations understand AWS Security and what it means to operate securely on the cloud. And I focus on helping the industry achieve these same goals.

What’s your favorite part of your job?

Helping customers and their executive leadership to understand the benefits of cloud security and how they can improve the overall security posture by using cloud features. Getting to show them how we can help drive road maps and new features and functions that they can use to secure their workloads (based on their valuable feedback) is very rewarding.

Tell us about the open source communities you support. Why they are important to AWS?

The open source community is important to me for a couple of reasons. First, it helps enable and inspire innovation by inviting the community at large to expand on the various use cases our services provide. I also really appreciate how customers enable other customers by not only sharing their own innovations but also inviting others to contribute and further improve their solutions. I have a couple of open source repositories that I maintain, where I put various security automation tools that I’ve built to show various innovative ways that customers can use our services to strengthen their security posture. Even if you don’t use open source in your company, you can still look at the vast number of projects out there, both from customers and from AWS, and learn from them.

What does cloud security mean to you, personally?

For me, it represents the possibility of creating efficient, secure solutions. I’ve been working in various security roles for almost twenty-five years, and the ability we have to protect data and our infrastructure has never been stronger. We have an incredible opportunity to solve challenges that would have been insurmountable before, and this leads to one thing: trust. It allows us to earn trust from customers, trust from users, and trust from the industry. It also enables our customers to earn trust from their users.

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

The opportunities far outweigh the challenges, honestly. The different methods that customers and users have to gain visibility into what they’re actually running is mind-blowing. That visibility is a combination of knowing what you have, knowing what you run, and knowing all the ins and outs of it. I still hear people talking about that server in the corner under someone’s desk that no one else knows about. That simply doesn’t exist in the cloud, where everything is an API call away. If anything, the challenge lies in finding people who want to continue driving the innovation and solving the hard cases with all the technology that’s at our fingertips.

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

One shift we’re already seeing is that compliance is becoming a natural part of the security and innovation conversation. Previously, “compliance” meant that maybe you had a specific workload that needed to be PCI-compliant, or you were under HIPPA requirements. Nowadays, compliance is a more natural part of what we do. Privacy is everywhere. It has to be everywhere, based on requirements like GDPR, but we’re seeing that a lot of these “have to be” requirements turning into “want to be” requirements — we’re not distinguishing between the users that are required to be protected and the “regular” users. More and more, we’re seeing that privacy is always going to have a seat at the table, which is something we’ve always wanted.

At re:Invent 2018, you’re presenting two sessions together with Andrew Krug. How did you choose your topics?

They’re a combination of what I’m passionate about and what I see our customers need. This is the third year I’ve presented my Five New Security Automations Using AWS Security Services & Open Source session. Previously, I’ve also built boot camps and talks around secure automation, DevSecOps, and container security. But we have a big need for open source security talks that demonstrate how people can actually use open source to integrate with our services — not just as a standalone piece, but actually using open source as inspiration for what they can build on their own. That’s not to say that AWS services aren’t extremely important. They’re the driving force here. But the open source piece allows people to adapt solutions to their specific needs, further driving the use cases together with the various AWS security services.

What are you hoping that your audience will take away from your sessions?

I want my audience to walk away feeling that they learned something new, and that they can build something that they didn’t know how to before. They don’t have to take and use the specific open source tools we put out there, but I want them to see our examples as a way to learn how our services work. It doesn’t matter if you just download a sample script or if you run a full project, or a full framework, but it’s important to learn what’s possible with services beyond what you see in the console or in the documentation.

Any tips for first-time conference attendees?

Plan ahead, but be open to ad-hoc changes. And most importantly, wear sneakers or comfortable walking shoes. Your feet will appreciate it.

If you had to pick any other job, what would you want to do with your life?

If I picked another role at Amazon, it would definitely be a position around innovation, thinking big, and building stuff. Even if it was a job somewhere else, I’d still want it to involve building, whether woodshop projects or a robot. Innovation and building are my passions.

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.


Henrik Johansson

Henrik is a Principal in the Office of the CISO at AWS Security. With over 22 years of experience in IT with a focus on security and compliance, he focuses on establishing and driving CISO-level relationships as a trusted cloud security advisor who has a passionate focus on developing services and features for security and compliance at scale.

AWS Security Profiles: Sam Koppes, Senior Product Manager

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-sam-koppes-senior-product-manager/

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?

I’ve been with AWS for a year, and I’m a Senior Product Manager for the AWS CloudTrail team. I’m responsible for product roadmap decisions, customer outreach, and for planning our engineering work.

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

I work on a technical product, and for any tech product, responsibility is split in half: We have product managers and engineering managers. Product managers are responsible for what the product does. They’re responsible for figuring out how it behaves, what needs it addresses, and why customers would want it. Engineering managers are responsible for figuring out how to make it. When you look to build a product, there’s always the how and the what. I’m responsible for the what.

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

The scale challenges that we’re facing today are extremely interesting. We’re allowing customers to build things at an absolutely unheard-of scale, and bringing security into that mix is a challenge. But it’s also one of the great opportunities for AWS — we can bring a lot of value to customers by making security as turnkey as possible so that it just comes with the additional scale and additional service areas. I want people to sleep easy at night knowing that we’ve got their backs.

What’s your favorite part of your job?

When I deliver a product, I love sending out the What’s New announcement. During our launch calls, I love collecting social media feedback to measure the impact of our products. But really, the best part is the post-launch investigation that we do, which allows us understand whether we hit the mark or not. My team usually does a really good job of making sure that we deliver the kinds of features that our customers need, so seeing the impact we’ve had is very gratifying. It’s a privilege to get to hear about the ways we’re changing people’s lives with the new features we’re building.

How did you choose your particular topic for re:Invent this year?

My session is called Augmenting Security Posture and Improving Operational Health with AWS CloudTrail. As a service, CloudTrail has been around a while. But I’ve found that customers face knowledge gaps in terms of what to do with it. There are a lot of people out there with an impressive depth of experience, but they sometimes lack an additional breadth that would be helpful. We also have a number of new customers who want more guidance. So I’m using the session to do a reboot: I’ll start from the beginning and go through what the service is and all the things it does for you, and then I’ll highlight some of the benefits of CloudTrail that might be a little less obvious. I built the session based on discussions with customers, who frequently tell me they start using the service — and only belatedly realize that they can do much more with it beyond, say, using it as a compliance tool. When you start using CloudTrail, you start amassing a huge pile of information that can be quite valuable. So I’ll spend some time showing customers how they can use this information to enhance their security posture, to increase their operational health, and to simplify their operational troubleshooting.

What are you hoping that your audience will take away from it?

I want people to walk away with two fistfuls of ideas for cool things they can do with CloudTrail. There are some new features we’re going to talk about, so even if you’re a power user, my hope is that you’ll return to work with three or four features you have a burning desire to try out.

What does cloud security mean to you, personally?

I’m very aware of the magnitude of the threats that exist today. It’s an evolving landscape. We have a lot of powerful tools and really smart people who are fighting this battle, but we have to think of it as an ongoing war. To me, the promise you should get from any provider is that of a safe haven — an eye in the storm, if you will — where you have relative calm in the midst of the chaos going on in the industry. Problems will constantly evolve. New penetration techniques will appear. But if we’re really delivering on our promise of security, our customers should feel good about the fact that they have a secure place that allows them to go about their business without spending much mental capacity worrying about it all. People should absolutely remain vigilant and focused, but they don’t have to spend all of their time and energy trying to stay abreast of what’s going on in the security landscape.

What’s the most common misperception you encounter about cloud security and compliance?

Many people think that security is a magic wand: You wave it, and it leads to a binary state of secure or not secure. And that’s just not true. A better way to think of security is as a chain that’s only as strong as its weakest link. You might find yourself in a situation where lots of people have worked very hard to build a very secure environment — but then one person comes in and builds on top of it without thinking about security, and the whole thing blows wide open. All it takes is one little hole somewhere. People need to understand that everyone has to participate in security.

In your opinion, what’s the biggest challenge that people face as they move to the cloud?

At AWS, we follow this thing called the Shared Responsibility Model: AWS is responsible for securing everything from the virtualization layer down, and customers are responsible for building secure applications. One of the biggest challenges that people face lies in understanding what it means to be secure while doing application development. Companies like AWS have invested hugely in understanding different attack vectors and learning how to lock down our systems when it comes to the foundational service we offer. But when customers build on a platform that is fundamentally very secure, we still need to make sure that we’re educating them about the kinds of things that they need to do, or not do, to ensure that they stay within this secure footprint.

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

I think we’ll see a tremendous amount of growth in the application of machine learning and artificial intelligence. Historically, we’ve approached security in a very binary way: rules-based security systems in which things are either okay or not okay. And we’ve built complex systems that define “okay” based on a number of criteria. But we’ve always lacked the ability to apply a pseudo-human level of intelligence to threat detection and remediation, and today, we’re seeing that start to change. I think we’re in the early stages of a world where machine learning and artificial intelligence become a foundational, indispensable part of an effective security perimeter. Right now, we’re in a world where we can build strong defenses against known threats, and we can build effective hedging strategies to intercept things we consider risky. Beyond that, we have no real way of dynamically detecting and adapting to threat vectors as they evolve — but that’s what we’ll start to see as machine learning and artificial intelligence enter the picture.

If you had to pick any other job, what would you want to do with your life?

I have a heavy engineering background, so I could see myself becoming a very vocal and customer-obsessed engineering manager. For a more drastic career change, I’d write novels—an ability that I’ve been developing in my free time.

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.


Sam Koppes

Sam is a Senior Product Manager at Amazon Web Services. He currently works on AWS CloudTrail and has worked on AWS CloudFormation, as well. He has extensive experience in both the product management and engineering disciplines, and is passionate about making complex technical offerings easy to understand for customers.

AWS Security Profiles: Alana Lan, Software Development Engineer; Shane Xu, Technical Program Manager

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-alana-lan-software-development-engineer-shane-xu-technical-program-manager/

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?

Alana: I’m a software development engineer, and I’ve been here for a year and a half. I’m on the Security Assessment and Automation team. My team’s main purpose is to develop tools that help internal teams save time. For example, we build tools to help people find resources for external customers, like information control frameworks. We also build services that aggregate data about AWS resources that other teams can use to identify critical resources.

Shane: I started around the same time as Alana — we’re part of the same team. I’m a Technical Program Manager, and my role is to perform deep-dives into different security domains to investigate the effectiveness of our controls and then propose ways to automate the monitoring and mitigation of those controls. I like to explain my role using a metaphor: If AWS Security is the guardian of the AWS Cloud, then the role of the Security Assurance team is to make sure the guardians have the right superpowers. And the goal of my team is to ensure those superpowers are automated and always monitored so that they’re always available when needed.

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

Alana: I tell people that there are many AWS services, and many teams working to make those services available globally. My work is to make the jobs of those teams easier with tools and resources that reduce manual effort and allow them to serve customers better.

Shane: I normally tell people that my role is related to security automation. Those two words tend to make sense to people. If they want more detail, I explain that my role is to automate the compliance managers out of the repetitive aspects of their jobs. Compliance managers cut tickets to request different kinds of evidence to show to auditors. My role is to automate this so that compliance managers don’t need to go through a long, manual process and so they can focus on more important tasks.

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

Alana: We’re working on a service that aggregates data about Amazon and AWS resources to provide ways to find relationships between these resources. We’re also experimenting with Amazon Neptune (a graph database) plus some new features of other services to help our teams help customers. Sometimes, SDEs seek us out for help with specific needs, and we try to encourage that: We want to emphasize how important security is. I like getting to work on a team that grapples with abstract concepts like “security” and “compliance.”

Shane: I’m working on an initiative to reduce the manual effort required for data center audits. We’re a cloud company, which means we have data centers all over the world and they are critical infrastructure for AWS services and customer data. For compliance purposes, we need to do physical audits of all of those sites and a typical approach would be flying out to dozens of locations each year to examine the security and environmental controls we have in place. I’m working on a project that’s less manual and resource-heavy.

You’re involved with this year’s Security Jam at re:Invent. What’s a Security Jam?

Shane: The Security Jam is basically a hackathon. It’s an all-day event from 8 AM to 4 PM that includes a dozen challenges (one of which Alana and I are hosting). The doors open at 7 AM at the MGM Studio Ballroom, and you can sign up as a group, or we’ll randomly pair you as needed. Your team works through as many of the challenges as possible, with the goal of getting the high score. The challenges are intended to provide hands-on experience with how to use AWS services and configure them to make sure your environment is secure. The Jams are structured to accommodate AWS users of all levels.

What’s your Security Jam challenge about?

Shane: Last year, our challenge focused on ensuring an environment was secure and compliant. This year, we’re taking it one step further by focusing on continuous monitoring. It’s a challenge that’s relevant whether you’re a small company or a large enterprise: You can’t realistically have one person sitting in front of a dashboard 24/7. You need to find a way to continuously monitor your resources so that at any time, when a new resource becomes available and older ones are deprecated, you have an up-to-date snapshot of your compliance environment. For the Security Jam challenge, I provide a proof of concept that lets participants use AWS Config to configure some out-of-the-box rules (or develop new rules) to provide continuous monitoring of their environment. We’ve also added an API around this for people like compliance managers, who might not have a technical background but need to be able to easily get a report if they need it.

Alana: Customers have reported that AWS Config is very useful, so we built the challenge to expose more people to the service. It will give participants a foundation that they can use in the future to protect their data or services. It’s a starting point.

What knowledge or experience do you hope participants will gain by completing your challenge?

Alana: I want people to understand that AWS services are not difficult to use. For example, there are many open source AWS Lambda functions that can help protect your data with a few button clicks. Don’t be afraid to get started.

Shane: People sometimes think compliance is scary. I want the hands-on nature of the challenge to show people that we provide tools that will make your life, and your customers’ lives, easier. I also want people to learn ways of avoiding compliance fatigue. Automation makes it easier for you to focus on more innovative work. It’s the future of compliance.

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

Shane: The scope for compliance is getting larger and larger, and there will always be new revelations and new types of threats. Developing scalable solutions to help achieve compliance is an ongoing challenge, and one we can’t just throw human power at. That’s why automation is so important. The other challenge is that some people see compliance as a burden, when we want it to be an enabler. I want people to understand that it’s not just a regulation or a security best practice. Compliance is a way to enable growth.

Alana: If I worked on another team, I think it would have taken me several years to figure out how my daily job impacted the security and compliance of AWS as a whole. It’s hard to connect the coding of an individual project back to AWS Security. We’re encouraged to take trainings, and we know that it’s important to protect your data, but people don’t always understand why, exactly. It’s hard for individual contributors to get a sense of the big picture.

If you had to pick any other job, what would you want to do with your life?

Alana: If I wasn’t an SDE, I’d want to be a Data Scientist. I think it would be interesting to analyze data and figure out the trends.

Shane: I would really like to be involved in AI. There are so many unknowns right now, in terms of how to ensure AI that’s secure and ethical. I’d also like to be a teacher, or a university professor. When I was working on my Master’s degree, it was really difficult to get some practical skills, such as how to have a productive one-on-one with my manager, or what career paths are available in a security-related field. I like the idea of being able to use my industry experience to help other students.

What career advice do you have for someone just joining AWS?

Shane: There’s a lot of opportunity at AWS. During my first six months here, I was cautious: Because of my previous consulting background, I felt like I had to have a legit case to talk with leadership and take up their time. It’s certainly important that I value their time, but in general I’ve found people in senior positions to be very willing to engage with me. My advice is to not be afraid to reach out, grow your network, and learn new things.

Alana: I’d echo what Shane said. There are a lot of possibilities at AWS, so don’t be afraid to try something new.

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.


Alana Lan

Alana is a Software Development Engineer at AWS. She’s responsible for building tools and services to help with the operations of AWS security and compliance controls. Currently, she is obsessed with exploring AWS Services.


Shane Xu

Shane is a Technical Program Manager for Security Assessment and Automation at AWS. Shane brings together people, technology, and processes to invent and simplify security and compliance automation solutions. He’s a passionate learner and curious explorer at work and in life.

AWS Security Profiles: Matt Bretan, Principal Manager, AWS Professional Services

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-matt-bretan-principal-manager-aws-professional-services/

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?

I‘ve been with AWS Professional Services nearly five years. I run two teams: our Security Assurance and Advisory Practice team, and our Security Experience team. The Security Assurance and Advisory Practice team is responsible for working with our customers’ executive leadership to help them plan their security risk and compliance strategy when they move to AWS. Executives need to understand how to organize their teams and what tools and mechanisms they need in order to meet expected regulatory or policy-based controls. We help with that. It’s a relatively new team that we started up in early 2018.

The Security Experience team is responsible for our Jam platform, which is changing the way we help customers learn about AWS services and partners. Previously, when we went to a customer, we gave slide presentations about how to be secure on AWS and how to migrate to the cloud. At the end of the presentation, people could usually repeat definitions back at us, but when we put them in front of a keyboard and monitor, they were uncertain about what to do. So, we built out the Jam platform, which allows customers to get hands-on experiences across a wide variety of AWS services, plus some partner products as well. It’s a highly gamified way to learn.

What’s the most challenging part of your job?

How to scale our offerings. A lot of what we do is to work one-on-one with our customers. Part of my job is to figure out how to impact more customers. We don’t just want to work with the largest companies of the world, but rather we want to help all companies be more secure. So, I’m constantly asking myself how to create tools and offerings that are scalable enough to impact everyone, and that everyone can benefit from.

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

The Jam platform. It allows us to change the way that customers experience AWS, and the way that they learn about moving to the cloud. It’s a different way to think about learning — gamifying the cloud adoption process helps people actually experience the technology. It’s not just definitions on a slide deck anymore. People get to see the capabilities of AWS in action, and they’ll have that Jam experience as a foundation once they start building their own infrastructure.

What can people expect from your teams at re:Invent this year?

The Jam Lounge will be in the Tundra Lounge within the Partner Expo Center at the Venetian. You’ll be able to register for the Jam Lounge there, and from Monday night through Thursday night, you can take part in a number of challenges — everything from security to migration to data analytics. We’ll be showcasing five partner solutions as well. The cool thing about the Jam Lounge is that it’s a completely virtual event. Once you register for the event in the Partner Expo Center, you can take part in the challenges from anywhere at re:Invent. This means that you can gain hands on experiences with AWS and our partner solutions in between the other amazing sessions and activities that go on during re:Invent.

The Security Jam takes place on Thursday, and it’s purely security-focused. We’ll have 13 different challenges. There are 10 specifically around AWS services and three from partners, and they’ll highlight different cloud security scenarios that people might encounter on a day-to-day basis. You’ll get to go into AWS accounts that we provision for you, identify what is wrong, and then fix them to get them into a known good state.

We’re also hosting the Executive Security Simulation as part of the executive track. That one is a tabletop exercise to help attendees experience and think about security from a high level. We simulate the first two years in a company’s life as they adopt the cloud — including some of the decisions they have to make in this process — so that people can think through security adoption from a lens that’s less about technical implementation and more about high-level strategy.

You mentioned that the Security Jam is an example of gamified learning. Can you talk more about what that means?

People love the hands-on application of learning: Rather than reading definitions, you get to use the technology and experience it. And that’s what gamification does: It gives you the actual infrastructure with an actual problem, and you get to go in and fix it. Also, it plays well to peoples’ competitive side. We set participants up in teams, and you have to work together to solve problems and win. There’s a leader board and scoring with points and clues. Anyone can participate, get what they need out of it, have fun doing it, and feel successful at the end of the day. This is the third year we’ve run a Jam at re:Invent, and we’re excited to have everyone try brand-new challenges and learn about new services and ways to do things on AWS.

Any tips for first-time conference attendees?

This conference is a marathon and not a sprint! There are so many great sessions and activities that go on during the week, so spend a little bit of time now reviewing the agenda and figure out what is most important for you to attend. Prioritize those items, and then make sure to leave some time for some surprise announcements! For the Jam sessions, you actually get to interact with AWS and our partner solutions, so bring your laptop. But also, come with an open mind. I think the big thing here is that re:Invent is a learning event. But for our events, at the end, there are prizes!

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

I think a lot of the changes will be around the requirements themselves. Today, many of the requirements in the compliance space center around specific technologies, rather than around the risk itself. Often, these programs are also primarily written around a traditional data center model where someone deploys an application onto a server and then doesn’t touch it for years. I think as compliance programs mature, we’ll shift to more of a risk-based process that puts the overall security and protection of customers first while taking into account how technology is constantly changing.

What does cloud security mean to you, personally?

I use technology: I stream videos, I do online banking, I buy things online, and I have an IoT-connected house. So, for me, cloud security is a way to protect my own interests and the interests of my family. I’m using these companies — often customers of ours — on a day-to-day basis. So the more I can do to ensure that they’re being secure with their implementations, the more secure I’ll be in the long run — and the more secure all consumers will be. The more I can do to proactively make it difficult for malicious parties to do harm, the safer and better all of our lives will be.

If you had to pick any other job, what would you want to do with your life?

My passion is building things. If I were to switch careers, I think I’d want to build physical structures, like houses or buildings. I believe there is a strong similarity between the work I do now around helping design security controls and the work that architects do when they design buildings. There are risks around building physical structures. You have to deal with things like lateral loads and entrance and exit controls. Technology involves a different kind of load, but in both cases, you have to go through a process of preparing for it and understanding it. I find that similarity fascinating.

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.


Matt Bretan

Matt travels the world helping customers move their most sensitive workloads onto AWS while trying to find the best airline snack. He won’t stop until he has figured out how to help everyone. When not working with customers, he is at home with his beautiful wife and three wonderful kids.

AWS Security Profiles: Phil Rodrigues, Principal Security Solutions Architect

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-phil-rodrigues-principal-security-solutions-architect/

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?

I’m a Principal Security Solutions Architect based in Sydney, Australia. I look after both Australia and New Zealand. I just had my two year anniversary with AWS. As I tell new hires, the first few months at AWS are a blur, after 6-12 months you start to get some ideas, and then after a year or two you start to really own and implement your decisions. That’s the phase I’m in now. I’m working to figure out new ways to help customers with cloud security.

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

In Australia, AWS has a mature set of financial services customers who are leading the way in terms of how large, regulated institutions can consume cloud services at scale. Many Aussie banks started this process as soon as we opened the region six years ago. They’re over the first hump, in terms of understanding what’s appropriate to put into the cloud, how they should be controlling it, and how to get regulatory support for it. Now they’re looking to pick up steam and do this at scale. I’m excited to be a part of that process.

What’s the most challenging part of your job?

Among our customers’ senior leadership there’s still a difference of opinion on whether or not the public cloud is the right place to be running, say, critical banking workloads. Based on anecdotal evidence, I think we’re at a tipping point leading to broad adoption of public cloud for the industry’s most critical workloads. It’s challenging to figure out the right messaging that will resonate with the boards of large, multi-national banks to help them understand that the technology control benefits of the cloud are far superior when it comes to security.

What’s your favorite part of your job?

We had a private customer security event in Australia recently, and I realized that: We now have the chance to do things that security professionals have always wanted to do. That is, we can automatically apply the most secure configurations at scale, ubiquitously across all workloads, and we can build environments that are quick to respond to security problems and that can automatically fix those problems. For people in the security industry, that’s always been the dream, and it’s a dream that some of our customers are now able to realize. I love getting to hear from customers how AWS helped make that happen.

How did you choose your particular topic for re:Invent this year?

Myles Hosford and I are presenting a session called Top Cloud Security Myths – Dispelled! It’s a very practical session. We’ve talked with hundreds of customers about security over the past two years, and we’ve noticed the types of questions that they ask tend to follow a pattern that’s largely dependent on where they are in their cloud journey. Our talk covers these questions — from the simple to the complex. We want the talk to be accessible for people who are new to cloud security, but still interesting for people who have more experience. We hope we’ll be able to guide everyone through the journey, starting with basics like, “Why is AWS more secure than my data center?”, up through more advanced questions, like “How does AWS protect and prevent administrative access to the customer environment?”

What are you hoping that your audience will take away from it?

There are only a few 200-level talks on the Security track. Our session is for people who don’t have a high level of expertise in cloud security — people who aren’t planning to go to the 300- and 400-level builder talks — but who still have some important, foundational questions about how secure the cloud is and what AWS does to keep it secure. We’re hoping that someone who has questions about cloud security can come to the session and, in less than an hour, get a number of the answers that they need in order to make them more comfortable about migrating their most important workloads to the cloud.

Any tips for first-time conference attendees?

You’ll never see it all, so don’t exhaust yourself by trying to crisscross the entire length of the Strip. Focus on the sessions that will be the most beneficial to you, stay close to the people that you’d like to share the experience with, and enjoy it. This isn’t a scientific measure, but I estimate that last year I saw maybe 1% of re:Invent — so I tried to make it the best 1% that I could. You can catch up on new service announcements and talks later, via video.

What’s the most common misperception you encounter about cloud security?

One common misperception stems from the fact that cloud is a broad term. On one side of the spectrum, you have global hyperscale providers, but on the opposite end, you have small operations with what I’d call “a SaaS platform and a dream” who might sell business ideas to individual parts of a larger organization. The organization might want to process important information on the SaaS platform, but the provider doesn’t always have the experience to put the correct controls into place. Now, AWS does an awesome job of keeping the cloud itself secure, and we give customers a lot of options to create secure workloads, but many times, if an organization asks the SaaS provider if they’re secure, the SaaS provider says, “Of course we’re secure. We use AWS.” They’ll give out AWS audit reports that shows what AWS does to keep the cloud secure, but that’s not the full story. The software providers operating on top of AWS also play a role in keeping their customers’ data secure, and not all of these providers are following the same mature, rigorous processes that we follow — for example, undergoing external third-party audits. It’s important for AWS to be secure, but it’s also important for the ecosystem of partners building on top of us to be secure.

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

The number of complex choices that customers must make when deciding which of our services to use and how to configure them. We offer great guidance through best practices, Well-Architected reviews, and a number of other mechanisms that guide the industry, but our overall model is still that of providing building blocks that customers must assemble themselves. We hope customers are making great decisions regarding security configurations while they’re building, and we provide a number of tools to help them do this — as do a number of third-parties. But staying secure in the cloud still requires a lot of choices.

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

I’m not losing much sleep over quantum computing and its impact on cryptography. I think that’s a while away. For me, the near future is more likely to feature developments like broad adoption of automated assurance. We’ll move away from a paper-based, once-a-year audits to determine organizations’ technology risk, and toward taking advantage of persistent automation, near-instant visibility, and being able to react to things that happen in real-time. I also think we’ll see a requirement for large organizations who want to move important workloads to the cloud to use security automation. Regulators and the external audit community have started to realize that automated security is possible, and then they’ll push to require it. We’re already seeing a handful of examples in Australia, where regulators who understand the cloud are asking to see evidence of AWS best practices being applied. Some customers are also asking third-party auditors not to bring in a spreadsheet but rather to query the state of their security controls via an API in real-time or through a dashboard. I think these trends will continue. The future will be very automated, and much more secure.

What does cloud security mean to you, personally?

My customer base in Australia includes banks, governments, healthcare, energy, telco, and utility. For me, this drives home the realization that the cloud is the critical digital infrastructure of the future. I have a young family who will be using these services for a long time. They rely on the cloud either as the infrastructure underneath another service they’re consuming — including services as important as transportation and education — or else they access the cloud directly themselves. How we keep this infrastructure safe and secure, and how we keep peoples’ information private but available affects my family.

Professionally, I’ve been interested in security since before it was a big business, and it’s rewarding to see stuff that we toiled on in the corner of a university lab two decades ago gaining attention and becoming best practice. At the same time, I think everyone who works in security thrives on the challenge that it’s not simple, it’s certainly not “done” yet, and there’s always someone on the other side trying to make it harder. What drives me is both that professional sense of competition, and the personal realization that getting it right impacts me and my family.

What’s the one thing a visitor should do on a trip to Sydney?

Australia is a fascinating place, and visitors tend to be struck by how physically beautiful it is. I agree; I think Sydney is one of the most beautiful cities in the world. My advice is to take a walk, whether along the Opera House, at Sydney Harbor, up through the botanical gardens, or along the beaches. Or take a ferry across to the Manly beachfront community to walk down the promenade. It’s easy to see the physical beauty of Sydney when you visit — just take a walk.

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.


Phil Rodrigues

Phil Rodrigues is a Principal Security Solutions Architect for AWS based in Sydney, Australia. He works with AWS’s largest customers to improve their security, risk, and compliance in the cloud. Phil is a frequent speaker at AWS and cloud events across Australia. Prior to AWS, he worked for over 17 years in Information Security in the US, Europe, and Asia-Pacific.

AWS Security Profiles: Ken Beer, General Manager, AWS Key Management Service

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-ken-beer-general-manager-aws-key-management-service/

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?

I’ve been here a little over six years. I’m the General Manager of AWS Key Management Service (AWS KMS).

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

For any kind of product development, you have the builders and the sellers. I manage all of the builders of the Key Management Service.

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

The work that gets me excited isn’t always about new features. There’s also essential work going on to keep AWS KMS up and running, which enables more and more people to use it whenever they want. We have to maintain a high level of availability, low latency, and a good customer experience 24 hours a day. Ensuring a good customer experience and providing operational excellence is a big source of adrenaline for service teams at AWS — you get to determine in real time when things aren’t going well, and then try to address the issue before customers notice.

In addition, we’re always looking for new features to add to enable customers to run new workloads in AWS. At a high level, my teams are responsible for ensuring that customers can easily encrypt all their data, whether it resides in an AWS service or not. To date, that’s primarily been an opt-in exercise for customers. Depending on the service, they might choose to have it encrypted — and, more specifically, they might choose to have it encrypted under keys that they have more control over. In a classic model of encryption, your data is encrypted at storage — think of BitLocker on your laptop — and that’s it. But if you don’t understand how encryption works, then you don’t appreciate the fact that encrypted by default doesn’t necessarily provide the security you think it does if the person or application that has access to your encrypted data can also cause your keys to be used whenever it wants to decrypt your data. AWS KMS was invented to help provide that separation: Customers can control who has access to their keys and enable how AWS services or their own applications make use of those keys in an easy, reliable, and low cost way.

What’s the most challenging part of your job?

It depends on the project that’s in front of me. Sometimes it’s finding the right people. That’s always a challenge for any manager at AWS, considering that we’re still in a growth phase. In my case, finding people who meet the engineering bar for being great computer scientists is often not enough — I’ve got to find people who appreciate security and have a strong ethos for maintaining the confidentiality of customer data. That makes it tougher to find people who will be a good fit on my teams.

Outside of hiring good people, the biggest challenge is to minimize risk as we constantly improve the service. We’re trying to improve the feature set and the customer experience of our service APIs, which means that we’re always pushing new software — and every deployment introduces risk.

What’s your favorite part of your job?

Working with very smart, committed, passionate people.

How did you choose your particular topic for re:Invent this year?

For the past four years, I’ve given a re:Invent talk that offered an overview of how to encrypt things at AWS. When I started giving this talk, not every service supported encryption, AWS KMS was relatively new, and we were adding a lot of new features. This year, I was worried the presentation wouldn’t include enough new material, so I decided to broaden the scope. The new session is Data Protection: Encryption, Availability, Resiliency, and Durability, which I’ll be co-presenting with Peter O’Donnell, one of our solution architects. This session focuses on how to approach data security and how to think about access control of data in the cloud holistically, where encryption is just a part of the solution. When we talk to our customers directly, we often hear that they’re struggling to figure out which of their well-established on-premises security controls they should take with them to the cloud — and what new things should they be doing once they get there. We’re using the session to give people a sense of what it means to own logical access control, and of all the ways they can control access to AWS resources and their data within those resources. Encryption is another access control mechanism that can provide strong confidentiality if used correctly. If a customer delegates to an AWS managed service to encrypt data at rest, the actual encipherment of data is going to happen on a server that they can’t touch. It’s going to use code that they don’t own. All of the encryption occurs in a black box, so to speak. AWS KMS gives customers the confidence to say, “In order to get access to this piece of data, not only does someone have to have permission to the encrypted data itself in storage, that person also has to have permission to use the right decryption key.” Customers now have two independent access control mechanisms, as a belt-and-suspenders approach for stronger data security.

What are you hoping that your audience will take away from it?

I want people to think about the classification of their data and which access control mechanisms they should apply to it. In many cases, a given AWS service won’t let you apply a specific classification to an individual piece of data. It’ll be applied to a collection or a container of data — for example, a database. I want people to think about how they’re going to define the containers and resources that hold their data, how they want to organize them, and how they’re going to manage access to create, modify, and delete them. People should focus on the data itself as opposed to the physical connections and physical topology of the network since with most AWS services they can’t control that topology or network security — AWS does it all for them.

Any tips for first-time conference attendees?

Wear comfortable shoes. Because so many different hotels are involved, getting from point A to point B often requires walking at a brisk pace. We hope a renewed investment in shuttle buses will help make transitions easier.

What’s the most common misperception you encounter about encryption in the cloud?

I encounter a lot of people who think, “If I use my cloud provider’s encryption services, then they must have access to my data.” That’s the most common misperception. AWS services that integrate with AWS KMS are designed so that AWS does not have access to your data unless you explicitly give us that access. This can be a hard concept to grasp for some, but we put a lot of effort into the secure design of our encryption features and we hold ourselves accountable to that design with all the compliance schemes we follow. After that, I see a lot of people under the impression that there’s a huge performance penalty for using encryption. This is often based on experiences from years ago: At the time, a lot of CPU cycles were spent on encryption, which meant they weren’t available for interesting things like database searches or vending web pages. Using the latest hardware in the cloud, that’s mostly changed. While there’s a non-zero cost to doing encryption (it’s math and physics, after all), AWS can hide a lot of that and absorb the overhead on behalf of customers. Especially when customers are trying to do full-disk encryptions for workloads running on Amazon Elastic Compute Cloud (Amazon EC2) with Amazon Elastic Block Store (Amazon EBS), we actually perform the encryption on dedicated hardware that’s not exposed to the customer’s memory space or compute. We’re minimizing the perceived latency of encryption, and we all but erase the performance cost in terms of CPU cycles for customers.

What are some of the blockers that customers face when it comes to using cryptography?

There are some customers who’ve heard encryption is a good idea — but every time they’ve looked at it, they’ve decided that it’s too hard or too expensive. A lot of times, that’s because they’ve brought in a consultant or vendor who’s influenced them to think that it would be expensive, not just from a licensing standpoint but also in terms of having people on staff who understand how to do it right. We’d like to convince those customers that they can take advantage of encryption, and that it’s incredibly easy in AWS. We make sure it’s done right, and in a way that doesn’t introduce new risks for their data.

There are other customers, like banks and governments, who have been doing encryption for years. They don’t realize that we’ve made encryption better, faster, and cheaper. AWS has hundreds of people tasked with making sure encryption works properly for all of the millions of AWS customers. Most companies don’t have hundreds of people on staff who care about encryption and key management the way we do. These companies should absolutely perform due diligence and force us to prove that our security controls are in place and they do what we claim they do. We’ve found the customers that have done this diligence understand that we’re providing a consistent way to enforce the use of encryption across all of their workloads. We’re also on the cutting edge of trying to protect them against tomorrow’s encryption-related problems, such as quantum-safe cryptography.

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

I think we’ll see a couple of changes. The first is that we’ll see more customers use encryption by default, making encryption a critical part of their operational security. It won’t just be used in regulated industries or by very large companies.

The second change is more fundamental, and has to do with a perceived threat to some of today’s cryptography: There’s some evidence that quantum computing will become affordable and usable at some point in time — although it’s unclear if that time is 5 or 50 years away. But when it comes, it will make certain types of cryptography very weak, including the kind we use for data in transit security protocols like HTTPS and TLS. The industry is currently working on what’s called quantum-safe or post-quantum cryptography, in which you use different algorithms and different key sizes to provide the same level of security that we have today, even in the face of an adversary that has a quantum computer and can capture your communications. As encryption algorithms and protocols evolve to address this potential future risk, we’ll see a shift in the way our devices connect to each other. Our phones, our laptops, and our servers will adopt this new technology to ensure privacy in our communications.

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.


Ken Beer

Ken is the General Manager of the AWS Key Management Service. Ken has worked in identity and access management, encryption, and key management for over 6 years at AWS. Before joining AWS, Ken was in charge of the network security business at Trend Micro. Before Trend Micro, he was at Tumbleweed Communications. Ken has spoken on a variety of security topics at events such as the RSA Conference, the DoD PKI User’s Forum, and AWS re:Invent.

AWS Security Profiles: Nihar Bihani, Senior Manager; Jeff Lyon, Systems Development Manager

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-nihar-bihani-senior-manager-jeff-lyon-systems-development-manager/

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?

Jeff: I’ve been with AWS for four years. I started as a Product Manager before transitioning into my current role as a Systems Development Manager where I lead the AWS DDoS Response Team. The AWS DDoS Response Team is the group that defends the Amazon infrastructure against denial-of-service attacks, in addition to protecting many of our customers against the impact of those attacks on their own applications.

Nihar: I’ve been with AWS for nearly 10 years. I started as an intern. I’m now a Senior Manager for two customer-facing services. The first is AWS WAF. The other is AWS Firewall Manager. I’m responsible for managing the team that builds those services.

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

Jeff: We help AWS defend against outside attacks — external threats that might otherwise cause problems for people.

Nihar: I usually tell people that my job is to make sure the applications that are running on AWS stay secure. My team writes the software that helps keep these sites safe and secure.

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

Jeff: I’m excited about some things that are happening behind the scenes. When people hear about the DDoS Response Team, I think the picture that comes to mind is engineers answering tickets and working on individual problems. We do a bit of that, but we’re mostly focused on building automation to solve these problems at scale. What we’re trying to do is to remove the undifferentiated heavy lifting from something that used to be really complicated and difficult for developers to solve, allowing them to focus more on the applications running on our platform.

Nihar: Lots of things! Security is an area that customers take very seriously—and it’s also an area that we take very seriously. My team is working on initiatives in three broad areas. First, we’re going to make our existing services scale more, perform better, and be more available. Second, we’re investing in adding new features for both AWS WAF and AWS Firewall Manager — something that our customers tend to get very excited about because they can use those features right away to help make their applications more secure. The third major project is geographic expansion. We’re working on expanding the AWS WAF presence across more AWS regions.

What’s the most challenging part of your job?

Jeff: Solving problems at scale. If you think about the many different problems in distributed systems, solving them individually tends to be relatively easy. But when you think about them on a large scale, and then think about the number of points of presence within AWS regions that we have, and even the size of some of our customers’ applications, it becomes quite a different story. Being able to think through those problems and figure out how to implement solutions on a much larger scale is a unique challenge.

Nihar: The most challenging part of my job is to deliver everything that our customers need fast enough. It’s not because we don’t want to. We do. And we want to build solutions that are of high-quality. But we have limited resources, and there’s a finite number of things we can do with them. It’s really helpful when customers help us prioritize against their needs, since that allows us to iterate as quickly as we can while knowing that what we’re delivering will have the most impact for customers.

How did you choose your particular topic for re:Invent this year?

Jeff: Our session is about orchestrating perimeter security. Perimeter security is the concept of taking threats and mitigating them far away from the application itself. The session focuses on how to build a layer of defense that people can use to defend against things like external threats, application vulnerabilities, bad bots, and DDoS attacks. Our customers are interested in this topic, and we field a lot of questions like, “What are the best practices? What architectures should I consider?” So the goal of the session is to help people protect their AWS resources so that they can spend more time building their applications and less time worrying about security threats. The “orchestration” component comes into play for large organizations, who need to answer the question, “How do you do that and manage it at scale?” For a large organization with a lot of applications, you have to ensure that if you build out a security policy, any given change will take effect across the entire application. You need a centralized way of doing that. So we’ll also talk about the capabilities that AWS offers via AWS Firewall Manager, which allows customers to orchestrate security policies on behalf of AWS WAF. We’ll discuss ways you can lock down your VPC network access control list, plus other strategies that a centralized security team can use to make sure that there’s a ubiquitous protection layer for the entire application.

Nihar: I also want to emphasize that this approach allows customers to achieve a strong security posture for their applications without the need to re-architect any of the applications or any of the infrastructure that’s already running on AWS. We want to dispel the idea that customers will have to do a ton of work. You won’t, and yet you’ll be able to improve the availability of your applications and benefit from being compliant with many regulatory requirements. Perimeter security is like building a wall around a castle you’ve already built. You don’t have to renovate the castle. You can build the wall, and maybe fill it with security guards, or put cameras on it: you haven’t changed your castle at all, but it’s so much more secure.

What are you hoping that your audience will take away from your session? What should they do differently as a result of it?

Jeff: I hope our customers will realize that there are lots of ways to architect and build things on AWS. And one of those ways is by using the AWS edge network as a tool to mitigate threats. We want them to understand the differentiating capabilities that we provide with that edge network and to be able to up-level their security when they get back to the office.

Nihar: I want people to understand that making their applications more secure doesn’t take a lot of effort. There are tools available, and we’ll show them how to use those tools in their own service architectures. Some customers might not be aware of all the threats they should be protecting their applications from, so the session is also about educating our customers on potential threats and how to mitigate against those threats. Jeff and I live in this world, so we’re very aware.

Does your session require existing knowledge about the topic?

Jeff: There’s a lot of a value in this session for developers at different experience levels and across different applications, but it’ll be especially useful for application developers who’ve built on AWS and who’ve gone through our security best practices — but are looking for opportunities to do more.

Nihar: You don’t need to have an extensive background in security because we’ll cover some of the current threat landscape, in addition to covering some of the ways that you can defend against these threats.

What are the biggest misconceptions that people have about perimeter security?

Jeff: People sometimes think that the on-premise capabilities they’ve built for themselves are going to be lost when they move to the cloud. One of the things we do in our session is demonstrate how our customers actually retain all those capabilities. We’ve just made them easier to consume and understand.
Nihar: People also think sometimes that perimeter security isn’t beneficial, or that it’s too hard, or too expensive. To the first point, I’d say that there are a lot of “bad actors” out there, and consumers have high standards for availability and security when they use any application. As for difficulty and expense, these are exactly the things we have in mind — we’re doing our best to ensure that it’s a simple experience that’s affordable for everyone.

Can you tell us about some of the innovations AWS has made in perimeter security?

Jeff: My favorite is the way we’ve leveraged the AWS global infrastructure to be able to detect and mitigate threats at the point of ingress. If you think about distributed denial-of-service attacks, historically, the network of any given company might have multiple points of presence. But these individual points of presence might not all be prepared to handle a DDoS attack, and so you’d have to shunt the traffic off to much larger locations called “scrubbing centers” and then pull it back to the point of presence in order to serve your customers. That approach can be costly, it can be difficult to build at scale, and it can add a performance penalty—but it was historically the industry standard. One of the things we’ve created at AWS is a way to do this such that every point of presence in every AWS region has a system right there at the point of ingress that will inspect the traffic, decide if it’s valid to be passed to the customer’s application, and pass it without a noticeable performance penalty. That’s difficult to accomplish at scale.

Nihar: AWS WAF offers a flexible rule language with full API access, so many of our customers have built automations with it. For instance, customers see traffic coming to their applications and they evaluate their logs using some of the data processing tools AWS AWF has, and then they immediately turn around and programmatically create a new WAF rule, submit it to AWS WAF, and within minutes AWS WAF is starting to block that bad traffic. All of this can be automated, and that’s powerful. In addition to customers writing their own rules, we offer Managed Rules that are written, curated and managed by AWS Marketplace Sellers and can be easily deployed in front of your web applications.

AWS Firewall Manager is integrated with AWS Organizations and AWS Config with the goal of providing a consistent, reliable security posture for customers that have potentially hundreds or thousands of applications running on AWS. These customers often find it beneficial to use AWS Firewall Manager to programmatically protect all of their applications in a simple way rather than having to do a lot of undifferentiated heavy lifting by building Lambda functions and working with AWS Config and doing a lot of scripting. All that is doable, but AWS Firewall Manager simplifies the experience.

What does cloud security mean to you, personally?

Jeff: Cloud security to me means two different things, both related to the Shared Responsibility Model. There is security in the cloud and security of the cloud. Security of the cloud is AWS’s responsibility, and security in the cloud is our customer’s responsibility. Our engineers are responsible for building security into AWS services, so that when customers move to the cloud, some aspects of security are taken care of automatically. But there are other aspects that our customers remain responsible for. To me, cloud security means that we will take care of all the things we’re able to take care of for our customers. And for the things we can’t take care of — the things that our customers remain responsible for and will have to manage themselves — we’re going to at least make them easier to think about, easier to configure, and easier to manage at scale.

Nihar: Security is our highest priority. If we’re not secure, we don’t have a business. So in one word, cloud security for me is trust. Our customers have a high bar because their customers, their consumers, demand a very high security posture. And as Jeff said, security is certainly a shared responsibility. But for the pieces for which we’re responsible, we have set a very high bar for ourselves so we continue to earn customer trust.

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

Jeff: If you’re developing on AWS, you don’t have to worry about a lot of foundational things, like building a data center, figuring out where the power comes from, or managing the infrastructure. Security is the next frontier, where we can abstract and make it easier for our customers. I think that over the next several years, customers will see things get easier to manage and easier to think about. People won’t have to worry as much about the engineering behind the security. They’ll be able to express intent, which will be translated into security.

Nihar: I think we’re going to continue to add more learning and intelligence to our security services over the next several years, so we can be more proactive when it comes to the security and compliance of our customers’ applications. In practical terms, I think this means that we’ll innovate by building solutions that are really simple to use, targeted to each specific application, evolve with that application, yet work at AWS scale.

If you had to pick any other job, what would you want to do with your life?

Jeff: My dream job growing up was to be a police officer. I went through school and college thinking I’d pursue that dream and actually joined the Navy as a Master at Arms, which is a police officer in the Navy. I did that for nine years and was also an auxiliary Sheriff’s Deputy for two years. So I got a lot of law enforcement experience, which has actually benefited my career. Really law enforcement is all about problem solving. So coming to AWS, I was able to bring a lot of those skills with me.

Nihar: I like building things. It just resonates with me. Here at Amazon, we like building new things, launching them, and then going back to square one to do it all over again. I’m organized and meticulous, so I like to have the end goal in mind and then build up to that. If I weren’t in software engineering, I’d like to do something involving construction: You start with a vision and a flat piece of land — and how you get from there to the end goal of a finished building is a fascinating process to me.

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.


Jeff Lyon

Jeff leads technical operations for AWS Perimeter Protection, where he manages engineering and response teams who defend AWS against Distributed Denial of Service (DDoS) attacks, and other external threats. His teams’ responsibilities include the defense of the AWS network, the defense of AWS services, and responding to attacks on behalf of many AWS customers who rely on services like AWS Shield, AWS WAF, and AWS Firewall Manager. Prior to joining AWS, Jeff founded a startup that was focused on providing DDoS mitigation capabilities to large, distributed networks.


Nihar Bihani

Nihar leads the teams that built the AWS WAF and AWS Firewall Manager services. He joined Amazon in 2009 and has spent time in AWS Marketing and Amazon CloudFront teams, most recently leading Product Management for CloudFront. Nihar was also an intern with AWS in 2008. Prior to Amazon, Nihar worked at a start-up for a few years. Nihar has earned his BS in Computer Science and an MBA in Marketing and Finance.