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.

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 outTeleport, 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: Last week, I had laid the foundation for a core philosophy driving how I evaluate everything, especially in security. I try to always know the why: why something exists, why someone does a thing, or why an organization has a policy or a program. Now, let’s talk about defining the framework of your defensive security program. The sexy and exciting world of offensive security—red teams, penetration testing, hacking, or cracking—gets most of the attention when non-security people think about our work. The popularization of the hacker type in media and entertainment fuels many of these misconceptions, but the reality is that defensive security is far more important than offensive security. 

If you see defensive security depicted in the media at all, the person doing it is generally portrayed as inept. In fact, the opposite is true. Those of us in defensive security solve incredibly complex problems, often with insufficient resources and tools. For the record, I know your work defending systems is far more challenging, rewarding, and complicated than non-security people realize. I know defending systems can be confusing if that’s not your full-time job. 

I also know that there is solid science underlying our work. Understanding that science will increase your success when implementing your security program. This week, we’re discussing People, Process, and Technology, often called the “Golden Triangle.” This foundational framework applies to all successful security programs, even if the security program was not originally designed or written using this framework. The Golden Triangle is your how, or the principles of your security program. 

Unfortunately, too many people see defensive security as boring, and the people who implement it as buttoned-up indentured servants to corporate or government overlords. There’s far more science than art in our work versus the enticing cool factor of breaking into systems to steal away the crown jewels.

Golden Triangle: People, Process, and Technology, or PPT. Many of you may have heard of the People, Process, and Technology paradigm, but most of you won’t know what people mean by it. The reason PPT matters and is successful is because it’s a business process model. In other words, it’s a proven framework for building a successful and functional organization. The use of PPT in security was first popularized by Bruce Schneier in 1999. 

He references having used the model in a blog post in 2013, but I failed to find the original article. Since his first mention of it, the idea has taken root and is now part of the general toolkit and lexicon of security practitioners everywhere. PPT is wholly applicable to IT of course, although it’s less popular in IT circles. Let’s break it down.

People. The first of the triad—people—refers obviously to humans. This is the human impact on security. This certainly includes your security professionals and management, yet this also can include general employees or contractors of your organization depending on the scope of your security program. Security personnel are critical to the success of a security program from the CSO all the way down to individual contributors: the security analysts. 

Without the right people designing, implementing, and supporting your security initiative, your program is doomed to fail. You need to know that the people performing tasks and using tools are skilled in the right area so that you can be successful. You must populate your security teams with people well-versed in the business and technologies being protected and monitored, or if you cannot do that, you must provide basic resources and training to provide them with adequate knowledge to do the job. For example, you may be tempted to only hire generalist who know a little bit about everything without any depth of knowledge. But to build the most successful program, your people need domain knowledge. 

If you are protecting Windows systems and networks, you need to hire Windows experts and network engineers, or you need to bring your existing staff up to speed on these topics. To go a bit deeper into the people concepts, checkout CybSafe’s article, “What actually is “The human aspect of cyber security”?” Note this is not an endorsement for or against CybSafe, the company, its people, or its services. I don’t know enough about them to comment either way. However, it was a very good article.

Announcer: If your mean time to WTF for a security alert is more than a minute, it’s time to look atLacework. 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, visitlacework.com. That’slacework.com.

Jesse: Process. The second of the triad—process—refers to a defined series of tasks or actions that comprise the security program. There are actions performed by humans, or automated with machines or software to support the why of this security program. Because your security program requires actions to be taken, it will fail without properly defined and implemented processes. Ultimately, people interact with processes, whether a particular process is all human performed and driven, or wholly automated by machine or software, or any combination of the two. 

Defining these processes is key because if people don’t understand what they must do and how they must do it, they will fail at implementing and following the process. In security, this is particularly true because most processes consist of a combination of human performed and automated work. A breakdown in process could result in catastrophic security breach. For example, when SolarWinds failed to protect its source code supply chain, thousands of customers were breached. In this case, the company didn’t have a comprehensive process for ensuring the integrity of their source code. 

A retooling of the source code verification process could have prevented this from happening. You must define your organization’s key security processes, including system and service monitoring, asset tracking—which is both more and less difficult in cloud settings than traditional operations, in different ways—event alerting, incident declaration and response, and remediation. I will delve into the details of some of these processes in the future. The American Society for Quality, or ASQ, defines process by explaining different types of processes from an organizational view, and we tech people can learn from their work, see the ASQ article called “What is Process View of Work?” for larger understanding of process in this way.

Technology. The third part of the triad—technology—refers to all types of tools used by humans, either manually or through automation, to perform the tasks outlined in the processes in the security program. In security, there tends to be a much heavier reliance on technical tools than in some other areas of your organization. The reason for this may be obvious: by definition information or cybersecurity is the monitoring, alerting, and responding to things that happen on technical infrastructures of some sort… with some social engineering in there, too, but that’s a topic for another day. Especially in cloud environments, most security program processes can be automated with little or no human intervention. 

Indeed, many security processes must be automated or the work cannot be done. Ultimately, however, humans will be consuming the output of these various systems. However, you may not have the luxury of automating as much as another security group can, or you may not yet understand your environment enough to implement heavy automation. If that’s the case, you may end up with voids in your security program, places where analysis is not available or is unattainable because of your available technology. If that’s the case, you should document this unmitigated risk or vulnerability so that you can address the issue when resources become available. 

But know this: even small operations need some tools to have even a faint hope of catching incidents happening in their network. We live in an age of data, and our systems create too much of it at too high volumes at too fast of rates for a human to manually sift and sort through the data. Thus, you must define the types of tools needed to monitor your environment and respond to security incidents in your organization, even if some of those tools are just on your wish list for now.

Smartsheet has an in-depth explanation of the whole PPT framework. In there, everything you need to know about the people process technology framework, which has good descriptions of all the parts of the triad including a section on technology. The PPT model can be applied to an existing security program or used to build a new security program. Its flexibility and adaptability offer your organization the underlying structure to build or retool your security program into a robust defense system. By finding the why of your security program and defining the how using the People, Process, and Technology Model, you are well on your way to developing a successful security program. The next step is to determine the what of how you implement security monitoring and controls.

Tune in next week when I discussed the holy trinity of confidentiality, integrity, and availability.

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.