The one piece of advice that most AWS re:Inforce presenters agreed on
AWS re:Inforce was my first in-person tech conference. The variety of sessions to choose from was overwhelming at first. As someone new to the cloud security industry, I wasn’t sure if certain sessions would be too advanced, how I would remember all of the important points, or even how I would find my way around the convention center. The approach that I took was actually a recurring theme in nearly all of the presentations I watched—just start somewhere. Making small strides toward securing your environment is much better than doing nothing at all. That was the way I handled the conference—make a decision, show up to those sessions, and see what I come away with. I figured that even if only a point or two resonated with me, it was still a step toward building my understanding of security and the cloud. I ended up learning a lot and hearing from so many excellent presenters. Here are a few things I took away from the experience.
Starting somewhere is better than doing nothing at all
This concept was mentioned in some form at nearly every session I attended. The “Security mindfulness” session with Jenny Brinkley and Mia Farrington from AWS focused on progress over perfection. They explained that psychological safety is being able to speak up without fearing repercussions. Leaders can make their teams feel psychologically safe by facilitating team connections and conversations, talking to their team members to determine how they like to be recognized and appreciated, and encouraging and building safe spaces for people to develop their careers and do their best work. Many people avoid these conversations because they aren’t sure exactly how to have them. Mia and Jenny agreed that it’s better to be intentional and try than to do nothing at all. Even if you’re not sure how to have a conversation, you can always improve next time. You just need to start somewhere.
“What do we do first?” was a question that the Center for Internet Security (CIS) frequently heard from enterprises that wanted to protect themselves from cyberattacks. In “Raise your security posture with CIS security controls and benchmarks,” Phyllis Lee, Senior Director of Critical Security Controls at CIS, explained that some organizations are intimidated by all of the security frameworks out there and are confused about where to start, so instead of making progress, those organizations don’t do anything. CIS acknowledged that not all enterprises have the resources to implement all of the security measures right away, and they need a place to begin. That’s why CIS prioritized their critical security controls. Prioritizing recommendations gives teams a definite place to start. Even though they’re not doing everything at once, they are taking small steps to secure their environments.
Moving to the cloud is like building a city
In the session “Continuous compliance and auditing on AWS,” James Reid, CIO at JP Morgan compared moving to the cloud with building a city––a city has a few different housing types such as houses, townhouses, and apartments. However, apartment buildings are built to scale.
In apartment buildings, landlords want licensed professionals to install standard applications—for example, stoves—instead of each tenant installing their own. When those applications are installed by a licensed professional with experience, the landlord is confident that they’re trustworthy and the applications will run effectively. The same application from a trusted vendor is installed in each apartment unit. Because the amenities are consistent throughout all of the units, when something breaks or needs to be replaced, the landlord knows exactly how to fix any unit quickly and efficiently. They know who can help, the parts that they need, and where to get them, regardless of whether it’s the apartment on the first floor or the twentieth.
This is how moving to the cloud works too. Using tools like Terraform to build infrastructure as code (IaC) enables you to make your infrastructure resources (like servers and operating systems) a code, or a machine-readable file with definitions and instructions. It’s like if you took your stove in the apartment and used a tool to automatically convert it into a detailed set of instructions explaining what it is and how it was built and installed. You would then use those instructions as a baseline whenever you want to build more apartment units.
Every organization has basic services that they will need at a bare minimum to operate in the cloud, like a container registry, network security, and a database. Engineers don’’t need to spend time recreating these over and over; instead, the process can be automated. So, when a business is moving all of their data, applications, and processes to the cloud, if they use IaC—the machine-readable instructions—to set up their infrastructure in the cloud (instead of doing it manually), they can quickly create new, consistent versions of that infrastructure with security baked in, and the engineers can spend their time innovating instead of recreating the basic needs.
It’s just like how when you add more apartment units, you would order the same stove as in the other units. You know where to get it, how it works, and what to do if it breaks.
Writing helps security teams too
As a writer, I get excited whenever I hear anyone talk about the importance of writing. So, I was pleasantly surprised to hear Eric Brandwine and Hart Rossman spend a few minutes of their session, “Security operations at scale,” discussing how writing helps security teams, especially when major security issues arise. They said that writing helps teams organize their thoughts during chaotic times. After a security event, when everyone looks at the same words together, it makes it easier to be precise and reach the right decision faster. When you write things down, it helps you identify the gaps and what questions people might have, therefore improving your response.
It’s easy to write about security using inflammatory language—however, Eric and Hart said to avoid this because you don’’t want to drum out a false sense of urgency. Write the facts, and then the right level of urgency will be generated. State the conclusions rather than implying them. This leads to a calm, organized, and direct conversation about the path forward.
They said that after Log4j, while the issue was urgent, their AWS security teams still took the time to write down what they knew about the event, their recommendations, their questions, etc. They then realized that some things didn’t make sense, so they continued to refine. They also noticed portions where they knew people would have questions, and wondered why their teams did or did not do something, so they filled in that gap. They eventually ended up with a great summary of the event and had incredibly efficient conversations with leadership about next steps. While it started out messy, they iterated on the message until it became clear and concise—reinforcing the recurring theme to start somewhere, because it’s still better than doing nothing.
Unique and compelling perspectives from experts
As someone who is still learning the basics about both the cloud and security, I found each re:Inforce session incredibly valuable. The many talented presenters were excited to share stories and things they’ve learned throughout their security industry careers. Anyone who wasn’t already convinced of the importance of security definitely will be after hearing these presenters’ perspectives. If you weren’t able to attend, you can find the sessions on YouTube or read our blogs from AWS.
