Welcome and Why Does Security Matter?

Jesse Trucks is the Minister of Magic at Splunk, where he consults on security and compliance program designs and develops Splunk architectures for security use cases, among other things. He brings more than 20 years of experience in tech to this role, having previously worked as director of security and compliance at Peak Hosting, a staff member at freenode, a cybersecurity engineer at Oak Ridge National Laboratory, and a systems engineer at D.E. Shaw Research, among several other positions. Of course, Jesse is also the host of Meanwhile in Security, the podcast about better cloud security you’re about to listen to. In this episode, Jesse establishes the foundation for an effective security approach while touching upon the importance of security as a mindset instead of a tool, how security is often driven by management or budgetary concerns, which results in waste and frustration, the importance of understanding the why behind security, why organizations often lose sight of the fact that their security plans aren’t the actual goal—protecting data and infrastructure is, Simon Sinek and the neuroscience behind why it’s important to know why you are doing something, how purchasing the right tool is wasted resources without a success plan for implementing said tool, and more.

Links:


Transcript

Jesse: Welcome to Meanwhile in Security where I, your host Jesse Trucks, guides you to better security in the cloud.


Announcer: Are you building cloud applications with a distributed team? Check out  Teleport, an open-source identity-aware access proxy for cloud resources. Teleport provides secure access for anything running somewhere behind NAT SSH servers, Kubernetes clusters, internal web apps, and databases. Teleport gives engineers superpowers. Get access to everything via single sign-on with multi-factor authentication, list and see all SSH servers, Kubernetes clusters, or databases available to you, and get instant access to them using tools you already have. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. And best of all, Teleport doesn’t get in the way. Download Teleport at  goteleport.com. That’s  goteleport.com.


Jesse: Welcome to Meanwhile in Security. I think we all need a personal assistant to sift through the flood of security news and innovations coming at us. But even if each of us had a PA—and who am I kidding, almost none of us do—our assistants would need their own assistants just to handle the flood of information. I think most of us agree that information overload poses a significant challenge to many of us. And with that challenge comes risk. 


When I talk to people about security, most of them say they need a guide and translator to sort out the deluge of information they receive. More importantly, I've learned that missing key information related to security can jeopardize your organization's mission success, and security breaches are costly, both financially and in lost reputation. When my friends Corey and Mike at The Duckbill Group asked me to create Meanwhile in Security, I remembered my own struggle to stay on top of security news in addition to staying current with the IT operations I managed. I designed this newsletter and podcast with a goal of serving as your personal translator and guide. Each week, you can count on me to explain a security-related topic, whether it's a core security concept, a breakdown of the latest big security breach in the news, or a guide for implementing an operational security methodology. 


Of course, you might wonder why me? Why Jesse Trucks? What do I bring to this discussion? For more than 20 years, I've been in the trenches, managing operations and security for networks, systems, and applications, and working with public and private organizations of all sizes and types. I've done system forensics, managed defensive security and audits, and more. 


As both an individual contributor and in management, I've written documentation and reporting for users, system admins, and management, designed and implemented training, risk mitigation, and security programs, and helped companies, schools, hospitals, and government agencies in the US and elsewhere improve security operations and compliance, respond to breaches and develop and implement risk analysis and mitigation strategies. I've lived through the industry transformation from bare metal, to virtualization, to containerization, and to cloud. This breadth and depth of experience gives me a unique understanding of systems on micro and macro scales. I know how to manage business needs and people. And I've learned that security is as much about conception of risk and risk mitigation as it is about the technology used to manage risk. 


Connecting business IT and security together is what I love doing. For me, translating security for all these audiences is one of my core personal missions. I've learned that having open dialogue and inviting questions is a powerful tool for creating meaningful change. So, here are my questions for you: what security concepts or topics confuse you? Be honest. 


What keeps you up at night about security? How can I help you better understand the importance of security? How can I help you translate security topics for your peers and managers? Where in your cloud journey do you need to better understand security issues and potential risks? Please send me your questions, concerns, and feedback. I can't wait to hear from you.


Find your why, or how to convince people that security matters. As I mentioned earlier, one thing I've learned during my career is that security is as much about people's conception of risks and risk mitigation as it is about the technology used to manage risk. In this first episode of Meanwhile in Security, I want to establish the foundation for an effective security approach. Driven by management and budgetary concerns, it's easy to get caught up in choosing the tools to manage security without understanding the why of what you are managing. This often leads to financial waste, frustration, and organization-wide resistance to security-related changes. In addition, it usually leads to poor security practices due to misalignment with the risk mitigation needs of the business. 


The first important lesson in managing security is to realize that security is a mindset, not a tool. We often hear security is a process, but this skips straight to implementation. I suggest that implementing and managing security is a process which encompasses people's actions with technical tools. Not every tool is a perfect fit for the job we need to complete. You wouldn't bring a hammer to a laundry pile any more than you would bring a washing machine to a building site. 


We can't know the tools we need if we don't have a roadmap for the protection we're seeking. Thus, it's important to understand that security and compliance aren't your primary goals. Protecting something is the goal. Designing and implementing security programs is a painstaking and time-intensive task, and organizations often go through many iterations before finding a program that works. That's because they lose sight of the fact that your security plan is not your actual goal. 


Protecting data or services, the infrastructure for those data or services, and the data integrity and services availability are the goals. We're all protecting something valuable, but if we lose sight of why we're protecting the things we're protecting, we lose the narrative on how to protect it. In other words, a security program is nothing without a why or a reason.


Corey: If your mean time to WTF for a security alert is more than a minute, it’s time to look at  Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you’re building a secure business on AWS with compliance requirements, you don’t really have time to choose between antivirus or firewall companies to help you secure your stack. That’s why Lacework is built from the ground up for the Cloud: low effort, high visibility and detection. To learn more, visit  lacework.com. That’s  lacework.com


Best-selling author and speaker Simon Sinek discusses the golden circle in his book Start With Why as well as his TED Talk, “How Great Leaders Inspire Action”, where he explains the neuroscience behind the importance of knowing why you do something. In these documents, Sinek outlines how in successful organizations, the why is the purpose that drives everything the organization does; the how is the principles that guide the work, and the what is the services offered by an organization. His approach mirrors what a successful security program should do. This science-based approach makes sense both from an organizational and an individual standpoint. Thus, what you are securing ultimately depends on determining why you are securing it. 


If you can identify the why underlying the security need, you will more easily decide and take control of what methods and tools you need to use. Frequently, I’ve seen an organization over-architect their security solutions and over-purchase tools to secure their data because they don't fundamentally have a grasp on why they are securing the information in the first place. This can also lead to shelfware status, even first tools that could be useful for risk mitigation and improving security. Purchasing the right tool is wasted resources without a success plan for implementing the tool. And you can't have a success plan without understanding why you need the tool in the first place. 

More importantly, you must understand that the why of securing your something is dependent upon your organization's mission and goals. Goal-driven change that makes sense to the end-user is change that users will embrace and even cheer-lead themselves. As an example, faculty and staff at a small community college were told that they had to change their passwords every 90 days. This led to general grumbling and unhappiness from all corners because the decision was communicated without a mission-dependent message attached to it. When the message was reframed as faculty and staff needed to change their password so that they could better protect student data, there was a wide-scale adoption of this security methodology. In a future issue, I will talk about better password policies, of course. 


In other words, faculty and staff cared about students, not passwords. By reframing the issue as a piece of the organization's fundamental mission of serving students, faculty and staff could see their compliance as part of their job and relate it to their organizationally related self-identity. Once you know why you're securing something, you can define the how and what of the security process. This approach can seem daunting, particularly if you're asked to dive into tools before determining your security goals. There's also the risk of people adopting a cowboy mentality early on because they want to spend time discussing feats of derring-do and other rodeo-like exploits without focusing on the steps that your organization needs to take to develop a security program that meets your current needs and that can scale with your growing security demands. 


When I'm developing a security program, I take a multi-pronged approach to form an often deceptively simple solution that can grow with the company's needs. By defining why you are protecting the something needing protection, you can define risks associated with your something. From your defined risks, you pivot to understanding what technical resources support the information or service or facility with your something needing protection. Knowing the technical infrastructure and services supporting or delivering your something means you are ready to develop the security program. 


To clarify, I define a security program as follows: A security program is a combination of principles, processes, and procedures implemented to mitigate or counter the defined risk to the things needing protection so the organization can continue supporting its mission. Technical tool selection and implementation can only happen when there is an envisioned and approved security program. Thus, the step that I see most organizations start first is actually the last step in developing a successful security program. This can be a shock to people in most organizations who are either excited about jumping feet first into security, or who feels a sense of urgency about implementing security solutions. However, in my experience, starting with the correct mindset allows us to do better risk mitigation, improve incident detection and response success and manage operational security later. Security can be confusing and complex, but it doesn't have to be. Starting with a strong foundation will result in operational and organizational success later. Tune in next week when I discuss people, process, and technology.


Jesse: Thanks for listening. Please subscribe and rate us on Apple and Google Podcast, Spotify, or wherever you listen to podcasts.


Announcer: This has been a HumblePod production. Stay humble.

Join the newsletter

Cloud Security For Humans

Got it. You're on the list!

Meanwhile in Security is a production of The Duckbill Group. Check out our other publications, Last Week in AWS, Screaming in the Cloud, and AWS Morning Brief.

© The Duckbill Group, 2021