Meanwhile in Security

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.

Show Notes:

Links:

• All Layers Are Not Created Equal”: https://blog.paloaltonetworks.com/2019/05/network-layers-not-created-equal/
• Help Net Security article: https://www.helpnetsecurity.com/2021/04/06/john-kindervag-zero-trust/

Transcript

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

Announcer: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial. That’s extrahop.com/trial.

Last week, I talked about Zero Trust as an office building where you have different ways of getting access to different parts of the building. Now, we’re going to talk about Zero Trust architecture or ZTA. That always makes me think of a ZA plan. What’s your plan? When the zombie apocalypse comes, you need to have Zero Trust. You do not trust anyone until you’ve confirmed that they are in fact, not a zombie.

But how do you do this? Well, first you have to define what a zombie is and you have to define what a human is. And you also have to define what kind of resources that they get to access. Zombies don’t get to access anything, especially not brains. But humans, they get to access all kinds of things: defensive positions, food, resources, medicine, shelter, and you have to confirm their identity every single time that they want to access something.

How do you do this? Well, the first thing you have to do is to find this, kind of, statically. Jesse comes up, shows he’s not zombie, gets something out of the kitchen. Next time, Jesse comes back, wants some medicine. You check; yep, Jesse’s still not a zombie; he gets to have some medicine.

However, in a Zero Trust world, what if one time somebody comes along, looks like Jesse, but he’s actually a zombie? He doesn’t get access because the risk has changed. This is exactly what Zero Trust is all about. It’s doing authentication and then authorization based on the current context, what’s happening right now. You let somebody in until it become a zombie.

You let an account into your resources to use your applications until it looks like it’s probably an attacker and not the actual real person behind that account. See how they are just like? When you’re implementing Zero Trust architectures, it’s not quite so as simple as seeing if somebody’s flesh is rotting off their bones. So, what is in a Zero Trust architecture? Well, there’s some basic components.

For instance, you have policy engine, which is basically what determines what the rules are and how they are applied in context, and you have Identity and Access Management—or IAM—and that is how you authenticate and how you determine whether an account actually is being driven by the person or thing that it should be. There’s of course monitoring systems to gather and report on your environment, and then you have a SIEM—or Security Information and Event Manager—and an optional security orchestration automation and response or SOAR tool. And the reason for this is so that you can change the architecture and the environment based on the current status of things. So, the policy engine can alter the environment in a feedback loop. And so the policy engine itself, as you can tell, is the brains behind everything, it sits in the middle and it drives the Zero Trust architecture to implement Zero Trust model in your environment.

So, how does this work? Well, if you talk to John Kindervag, the original creator of the Zero Trust model, he recently has an article where he was interviewed and he talked about some of the methodologies of doing this. So first, you define your protective surfaces—what are you protecting—then you map the transaction flows, what things are talking to other things, what systems are working together? How do your applications work? And then you architect the environment, so you have to put controls where the data or the services are, right?

So, right at every single application, which is great in a cloud environment, especially if you’re doing things like using Lambda functions, microservices, serverless functions, as well. And then you create a Zero Trust policy, and you do that by using the Kipling Method, which is the journalistic method of who, what, when, where, why, and how. There’s even an article that he wrote—John Kindervag that is—a couple of years ago, and he talks about how that applies.

It’s a great reading, but the main thing you have to get out of that is you have to answer all of these questions about what’s happening in your environment. And then lastly, you monitor and maintain your environment. You gather telemetry, you do machine learning and analytics, and you look at risk analysis, and you have automated responses going through your SOAR platform. Those are the five key things. In short, this is what you should take away from that article on Help Net Security.

One, define your protective service. Two, map your transaction flows. Three, architect your environment. Four, create your policies, your Zero Trust policies using the Kipling method. And five, monitor and maintain your environment just like anything else. Make sure it’s working, tune it, tweak it, evaluate it constantly.

This is a never-ending cycle where you should always be analyzing, tuning, changing because your environment that you’re protecting changes. And also the risks that you have will migrate and change over time. And technologies change; you’re going to be moving things, swapping things out, implementing new things. You have to keep this in mind and go through this cycle over and over again, always defining what the new thing is, figuring out how that interacts with other things and how accounts access data and resources within it. And also following your business; how are things changing in your organization? What other types of things are needed for you to do and to protect the environment as close as possible to those new services and thos...

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.

Show Notes:

Links:

• An introduction to the mathematics of trust in security protocols: https://ieeexplore.ieee.org/document/246634
• No More Chewy Centers: The Zero Trust Model Of Information Security: https://www.forrester.com/report/No+More+Chewy+Centers+The+Zero+Trust+Model+Of+Information+Security/-/E-RES56682
• 800-207, “Zero Trust Architecture”: https://csrc.nist.gov/publications/detail/sp/800-207/final

Transcript

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

Announcer: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial. That’s extrahop.com/trial.

Zero Trust is everywhere and nowhere. Over a decade old, Zero Trust feels like a new thing for many of us, but this feeling is likely because most of us experience or manage operational security methodologies following various forms of old-school trust and access models. In these models, a user or service authenticates to a network or service and gets all the things granted to them by their role or account permissions. This is often referred to as a trust but verify paradigm. Many organizations still use Virtual Private Network, or VPN, access mechanisms to connect from the outside to internal or trusted networks.

Accessing these internal or trusted networks provides access to a variety of systems with low to moderate security generally available to anyone granted access to the associated network. Each user accessing these networks is authenticated in some manner and then is trusted with the ability to connect to available resources. This is like many corporate office buildings: badge in or show ID to the security desk in the lobby, and you are granted access to wander the halls at will, with access to nearly any floor and office. In many modern office buildings, especially those with multiple tenants, there might be sections of the building that require additional verification using a badge reader or being cleared by guards at another security desk. This is like network segmentation trust models where each user must be granted specific access to certain networks.

Much like accessing different companies in the multi-tenant building works by being cleared by the front desk or using badge readers to unlock the doors and being granted access to all of the offices they’re in, access to resources and services on these network segments is controlled at the entrance by firewalls and/or authentication gateways. While most services today require authentication to get beyond the front door, similar to the network segmentation model but on an application or service level. Usually, there are static definitions of access granted to each user although most applications and services rely on role-based access controls or RBAC, these roles are statically defined with access to a list of resources, services, or capabilities for all users given that role. Searching network segmentation best practices finds dozens of results over the last couple of years with great advice on segmenting networks and limiting access to resources on those networks. Much of it is similar to one another and generally good advice to follow. I like to think of access to networks, resources, and services as being on a need-to-use and access to data on a need-to-know basis. Zero Trust upends the entire access model.

In June of 1993, IEEE published GJ Simmons’ article, “An introduction to the mathematics of trust in security protocols,” which, as the title implies, defines a mathematical approach to calculating trust in the context of computer systems. This concept opens possibilities for automating complex access authorization schemes. In 2009, while working as an analyst for Forrester Research, John Kindervag published a white paper titled “No More Chewy Centers: The Zero Trust Model Of Information Security,” outlining the Zero Trust model as a new paradigm for controlling access to resources and services.

Implementing a Zero Trust model creates the ability to dynamically grant access to resources and services based on real-time context, not statically defined need-to-use and need-to-know bases. Going back to the office building analogy, this is like the security station guards verifying things that are currently true before allowing you to access the building or any of the building spaces. For example, they could confirm you are currently employed by a tenant of the building and give you an access card that is good for one-time entry into your organization space. However, if you leave your offices and need to return, you have to go back to the security station to get another one-time entry pass to your suites. Even if you never leave the building, you still must go down to the security station to get your one-time access pass.

If you need to visit another space in the building, the security station guards would verify you have an appointment that grants you access to a different space, and they would give you a one-time access pass to enter those spaces. Once again, when you need to return to your own offices, you must go back for another pass to get in. This is exactly how Zero Trust works.

In an ideal Zero Trust world, every time you must access a network, resource, or service, you must also authenticate in some way to both verify your identity and to obtain authorization to access the network resource or service. This goes beyond having a token to use for multiple transactions, like when we store a website cookie or token to skip logging in when we return to a site. Instead, the site would require authentication for access authorization every time we return. In a realistic Zero Trust Architecture, or ZTA implementation, a cookie or token stored for a single session to skip login for every single page or image access is useful, but in a strict ZTA implementation, there would be an authenticat...

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.

Transcript

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

Announcer: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial. That’s extrahop.com/trial.

Jesse: This week, Verizon announced a deepening of its partnership with AWS with the launch of a private mobile edge computing, or MEC, service, which was previously only available from Verizon using Microsoft Azure cloud services. This new service complements the public MEC offering using AWS that Verizon introduced in August of 2020, and brings MEC solutions within reach of many organizations who could not consider implementing MEC in the past. What is mobile edge computing and what do these services provide? Mobile edge computing, sometimes called multi-access edge computing, is an infrastructure approach that provides cloud compute services at the edge of the network closest to the end-users of those services. To service implementations for mobile end-users, the hardware hosting the cloud services are co-located with the 4G or 5G networks rather than relying on transport to and from regular cloud services in addition to traversing the mobile networks.

This provides low-latency access for critical and real-time applications by users on those mobile networks. With the advent of 5G, latency on mobile networks has dropped down to or below levels commonly measured in landline-based networks. A common example cited is the use of MEC with self-driving cars for ultra-low latency access to traffic, weather, and other real-time conditions. However, a more practical example is using MEC to provide real-time analysis of crowd densities and line cues in public spaces such as theatres or public transit stations. The difference between public and private MEC is that, as the names imply, public implementations are accessible on the public internet, whereas private implementations are only accessible via internal private networks.

The latency for private MEC implementations tend to be much lower than public MEC implementations as well because the hardware running the compute services is physically located with the end-user systems, such as in a manufacturing plant or train station, but public MEC systems are usually located with a mobile network provider away from the end-users. The Verizon private MEC uses the AWS Outpost service, which is a hardware-based extension of AWS Cloud services physically located at the customer site rather than in AWS or Verizon data centers. These systems include Verizon 5G services for use on private local networks to provide low latency, easy to manage, and secure wireless access. Because of the co-location inside the customer network, the AWS Cloud services provided by this offering are only available to the customer hosting the hardware. The Verizon public MEC uses the AWS Wavelength service, which is a collection of AWS zones co-located with Verizon’s 5G network in select locations. These are generally available [over 00:03:53] AWS Cloud services, usable by nearly any AWS customer. Meanwhile, what about security and MEC?

Because the Verizon MEC services use existing AWS products, there are no new security mechanisms, tools, or requirements added to either of the public or private MEC services. The customer is required to manage all the usual security for systems and applications they deploy with either of the MEC solutions using the shared responsibility model with two slight differences with AWS Outpost. Let’s look a bit more closely at these two products and their security models.

AWS Outpost is essentially an AWS Cloud in a box or rack of servers physically installed in the customer’s location. This is remotely managed by AWS and provides a subset of the same AWS services, using the same APIs and other tools, as standard AWS offers in their normal regions. This is different than a wholly private and self-managed cloud implementation because AWS still manages the cloud infrastructure within the Outpost’s equipment.

Announcer: If you have several PostgreSQL databases running behind NAT, check out Teleport, an open-source identity-aware access proxy. Teleport provides secure access to anything running behind NAT, such as SSH servers or Kubernetes clusters and—new in this release—PostgreSQL instances, including AWS RDS. Teleport gives users superpowers like authenticating via SSO with multi-factor, listing and seeing all database instances, getting instant access to them using popular CLI tools or web UIs. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. Download Teleport at goteleport.com. That’s goteleport.com.

Jesse: With Outpost, there are two changes to the shared security model. Obviously, there’s an added layer of security managed by the customer to protect the physical hardware, and the customer must also provide adequate network access and security for the network. However, in terms of the systems, services, and applications running in the environment, operations and security are the same as running those same services in any other cloud environment. The hardware within the server or rack is built on the AWS Nitro platform. Nitro is a hardware implementation of the AWS hypervisor technology, coupled with chip-based hardware security subsystems.

This allows for a secure implementation of AWS Cloud services while also protecting customer environments and data. AWS Wavelength is the implementation of many of the familiar AWS Cloud services but co-located by AWS within mobile provider 5G networks, and uses the same shared responsibility model as normal AWS solutions. Essentially, Wavelength is used much like any other AWS environment. To use Wavelength, you must request access to the desired Wavelength zone or zones. Once access is granted, create or modify an existing AWS virtual private cloud, or VPC, with coverage extended to include the Wavelength’s zone or zones.

Then you deploy MEC-based services in the Wavelength zones as you normally would in other AWS regions and zones. Given this as an implementation of VPC, there are no additional security concerns outside the normal issues with managing a complex VPC environment. As always, yo...

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.

Links:

• "What is an Attack Surface? (And How to Reduce it)": And How to Reduce ithttps://www.okta.com/identity-101/what-is-an-attack-surface/
•  "Developing Cyber Resilient Systems: A Systems Security Engineering Approach": https://csrc.nist.gov/publications/detail/sp/800-160/vol-2/final

Transcript

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

Announcer: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial. That’s extrahop.com/trial.

Jesse: There’s a constant daily show of security-related news from all directions. It’s a storm that never abates. Sifting through it all feels daunting to most people, including many security professionals. We need a strategy to sort it all out and focus on the things that matter, as quickly as we can. [laugh]. The easy and terrifying answer is just to subscribe to all the newsletters for everything your organization uses or your group manages; go read the articles they point to, and [laugh] give up because it’s total information overload.

For some security people, this approach does make sense and it works; except the whole giving up part, of course. However, if this isn’t useful for most of us. As with anything driven by business needs, understanding how to find and evaluate useful security news starts with knowing your business. Whatever your role, you should understand how your work supports and furthers the organizational mission.

Understanding your mission leads to understanding your risks, therefore you will know your role in risk mitigation. This leads to understanding how and why your technological solutions both support your mission and mitigate your risks to that mission. Now, let’s look at how this foundational understanding of your business drives your consumption and evaluation of security news.

News strategy. It should be obvious that the role you and your technology have relative to the mission and risks determine the choosing of both the types and the sources of security news you should read. It is tempting to focus only on cloud-specific sources and topics, but running in the cloud does not obviate the need for the security of your systems, applications, and data. It is also true that ignoring cloud-specific security news is a bad idea. To determine which to focus on first or most, look at the likely exposure your infrastructure has in terms of your risks.

For example, if your application delivers the services of your business to external customers as opposed to an internal employees’ service, then most people will interact primarily with your application services presented by your systems. Your largest attack surface would be your service application, the data presented and used by your application, the operating system or microservice platform supporting your application, and the network infrastructure to tie it all together. We define attack surface as the collective group of services, systems, or data exposed to access by a potential adversary. In other words, if something can be touched on the network, it is part of the attack surface for initial intrusion. And if something on the system can be touched by local access, it is part of the attack surface for an attacker who has gained access beyond the network resources.

This means most of us have a primary or larger attack surface in the application and systems exposed in services delivery, and our cloud infrastructure underneath and supporting our systems and services is likely a secondary or smaller attack surface. For more reading on attack services, check out Okta’s article called “What is an Attack Surface? (And How to Reduce it)” and read some attention to the topic in the US National Institute of Standards and Technology or NIST Special Publication 800-160, Volume Two called “Developing Cyber Resilient Systems: A Systems Security Engineering Approach.” Wow, that’s a mouthful.

Announcer: If you have several PostgreSQL databases running behind NAT, check out Teleport, an open-source identity-aware access proxy. Teleport provides secure access to anything running behind NAT, such as SSH servers or Kubernetes clusters and—new in this release—PostgreSQL instances, including AWS RDS. Teleport gives users superpowers like authenticating via SSO with multi-factor, listing and seeing all database instances, getting instant access to them using popular CLI tools or web UIs. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. Download Teleport at goteleport.com. That’s goteleport.com.

It is generally the case for most people and organizations that non-cloud-specific news will provide the most return on our investment of time upfront, though this changes once processing and acting upon general security news become streamlined. Now, let’s talk about how to determine the usefulness of the news we encounter.

Evaluating news. Most of us would head straight to industry sources to see what the biggest news of the day is, but I suggest a different approach to triage your news needs. First, look at mainstream news sources such as the New York Times Washington Post, and the Guardian or even NPR, CNN, and BBC. Is there cybersecurity-related news showing up in many or all of these sources? If there is big news, it will be all over it with original source articles, and even articles summarizing those other news sources.

This will likely give you a general idea of the service or technology affected, which helps you determine whether further research is required to understand the impact it may have on your organization. These sources may not clarify what specific technical services or systems are involved, however. Once you found these big news items, search in the tech industry-focused sources to get more relevant detail that isn’t over-simplified for larger public audience. If there isn’t a big...

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.

Links:

• aws.amazon.com/compliance
• aws.training
• docs.microsoft.com/asure/security
• 
  

Transcript

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

Announcer: If you have several PostgreSQL databases running behind NAT, check out Teleport, an open-source identity-aware access proxy. Teleport provides secure access to anything running behind NAT, such as SSH servers or Kubernetes clusters and—new in this release—PostgreSQL instances, including AWS RDS. Teleport gives users superpowers like authenticating via SSO with multi-factor, listing and seeing all database instances, getting instant access to them using popular CLI tools or web UIs. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. Download Teleport at goteleport.com. That’s goteleport.com.

Jesse: Trilogy of Threes and a New Mantra. Trilogy of Threes. Good security practices and good security programs are built on three separate but intertwined principles, each of which has three parts. Simon Sinek’s Golden Circle framework lays the foundation for why you have a security program, which is a balance of risks to critical assets and services, and business objectives. The next part of how you apply the Golden Circle to your security program is about how you accomplish meeting these objectives and mitigating your risk through the People, Process, and Technology framework.

The PPT method helps you define the roles are needed to implement your security program, the overview of processes or actions within your security program, and the types of technology that supports your security program. The final part of how you apply the Golden Circle encompasses what specific things you do to implement your security program using the Holy Trinity of Security: confidentiality, integrity, and availability, or the CIA triad. In your security program, you should define who should be allowed access to any data or service, how you monitor and protect any data or services, and how you keep data or services available for users. Although understanding how to build a security program from nothing is incredibly important, most of us are already operating within an existing security program. Many of us will have influence only on the specific implementation of tools for the Holy Trinity, CIA. All this theory is crucial to understand, but you still have a job to do. So, let’s get practical.

Where to start today. Searching online for ‘Top X for AWS Security’ returns an expected long list of pages and there are shed-loads of fantastic tips in the results. However, reading through many of them, including AWS’s own blog entry on the topic, shows that proper cloud security involves large projects and possibly fully re-architecting your entire environment. As is often the case in these things, all the best security advice in the cloud has to do right security from the very beginning. Yet this is like discovering a new love of playing the piano late in life like I did, [laugh] but someone telling you the right way to learn to play the piano is to take lessons as a child. This isn’t so useful advice, now is it? Of course, it’s too late to become a child piano prodigy, but it’s not too late to take up the piano and do well.

Fundamentals. In traditional non-cloud environments, physical security for everything leading up to touching a machine is usually the purview of a different part of the organization, or an entirely different organization than the security team or group responsible for system network and application security. Generally, most information or cybersecurity starts with accessing the software-based systems on a physical device’s console or through a network connection. This, of course, includes accessing the network through some software path, usually a TCP or UDP-based protocol. In cloud environments, the cloud providers, such as Amazon Web Services—or AWS—Microsoft Azure, or Google Cloud Platform—GCP—maintains and is wholly responsible for all the physical environment and the virtual platform or platforms made available to their customers, including all security and availability required for protecting the buildings and hardware, up through the hypervisors presenting services allowing customers to run systems.

All security above the hypervisor is the customer’s responsibility, from the operating system or OS through applications and services running on these systems. For example, if you run Windows systems for Active Directory Services, and Linux systems for organizations’ online presence, then you own all things in the Windows and Linux OSes, services running on those systems, and the data on those systems. This is called the shared responsibility model. AWS provides details on their compliance site aws.amazon.com/compliance as well as in a short video on their training and certification site aws.training.

Microsoft describes their model on their documentation site docs.microsoft.com/asure/security. Google has lots of information in various places on their Google Cloud Platform GCP site, including a guided tour of their physical security for their data centers, but finding a simple explanation like the other two major services have available eluded me. Google does have a detailed explanation of their shared responsibility matrix, as they call it, which is an 87-page PDF. Luckily, given the overwhelming popularity over the other cloud providers, I tend to focus mostly on AWS. I didn’t read the whole GCP document.

Announcer: 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.

Jesse: basic AWS training. Amazon provides ample training and online tutorials on all things AWS. This includes AWS basics through advanced AWS architecture and various specialty areas like machine learning and security, among others. I...

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.

Links:

• EI-ISAC Cybersecurity Spotlight – CIA Triad: https://www.cisecurity.org/spotlight/ei-isac-cybersecurity-spotlight-cia-triad/
• What is the CIA Triad?: https://www.f5.com/labs/articles/education/what-is-the-cia-triad
• The CIA triad: Definition, components and examples: https://www.csoonline.com/article/3519908/the-cia-triad-definition-components-and-examples.html

Transcript

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

Announcer: If you have several PostgreSQL databases running behind NAT, check out Teleport, an open-source identity-aware access proxy. Teleport provides secure access to anything running behind NAT, such as SSH servers or Kubernetes clusters and—new in this release—PostgreSQL instances, including AWS RDS. Teleport gives users superpowers like authenticating via SSO with multi-factor, listing and seeing all database instances, getting instant access to them using popular CLI tools or web UIs. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. Download Teleport at goteleport.com. That’s goteleport.com.

Jesse: This is the t of a trilogy of threes that covers this core foundations of good security practices and good security programs. In the first issue of Meanwhile in Security, I explained how security is a mindset, not a tool, and the importance of understanding the why or the purpose for building a security program. This drives everything you do in your organization for securing your critical assets. The why is the core reason for having a security program.

Next, I laid the foundation for the how or the principles that guide the work of your security program by exploring the people, process, and technology paradigm upon which all successful security programs are based. Using PPT, you will build a longer-lasting, more dynamic, and highly successful security program.

Following Simon Sinek’s Golden Circle model, the outer ring is the what or services offered by an organization group or individual. In implementing and maintaining a security program, the how focuses on the confidentiality, integrity, and availability of all data and services offered within the scope of your security program. This is often called the holy trinity of security, or the CIA Triad. All actions performed and tools implemented in support of the security program stem from one of these fundamental precepts of security. Let’s dig into the parts of the Triad.

Confidentiality. The first part of the Triad is confidentiality, which is about controlling data in services’ access. In their article titled “EI-ISAC Cybersecurity Spotlight–CIA Triad,” the Center for Internet Security, or CIS, defines confidentiality as quote, “Data should not be accessed or read without authorization. It ensures that only authorized parties have access.” End quote. 

I expand on this definition to include services not just data. Every organization and person has data to protect. The traditional approach to confidentiality assumes that any service that touches the data falls within the scope of confidentiality, as a means to protect against disclosure of the data that services accesses. This can lead to a focus on robust and complete data access controls without similar attention paid to services that don’t directly touch data with those controls in place. However, I consider access to and use of services within the scope of confidentiality because protecting use of resources is often as important or in some cases more important than the data access. 

This is often the case with cloud-native applications using microservices. Many modern services can take action without accessing specific data sources, especially when the data source is defined as part of the microservices invocation. For example, consider an attacker who has pilfered a file or files from your services or systems or from some other source and wants to perform analysis or some type of processing of the file or files. If you run services useful to the attacker in this scenario, the attacker may not touch your data, but they may attempt to use your services without authorization. To apply confidentiality to your security program, determine and document what data in services are sensitive and require access protection. To do this you may need to track down data and service owners. This process is closely related to the why of your security program which ultimately exists to protect your data or services.

Announcer: 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.

Integrity. The second part of the Holy Trinity is integrity, which refers to keeping data intact and services functioning as expected. Anyone accessing data or a service should only have the ability to alter or remove any data or alter or repurpose a service when they are authorized for such actions. In Debbie Walkowski’s post for the F5 Labs site on July 9, 2019, “What is the CIA Triad?” she defines that integrity is about ensuring data quote, “Is correct, authentic and reliable.” End quote. 

Any authorized changes or removal of data or to services violates integrity, and are generally classified as alteration or modification attacks. Changes to some of your data can immediately call into question other data protected by the same security program and security monitoring or control tools. A type of integrity attack on software is a supply chain attack. This is an attack on any part of the process of creating, testing, and distributing software. This attack could be an...

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.

Links:

• “What actually is “The human aspect of cyber security”?”: https://www.cybsafe.com/community/blog/what-is-human-aspect-of-cyber-security/
• “What is Process View of Work?”: https://asq.org/quality-resources/process-view-of-work
• Smartsheet Complete Guide to the PPT Framework: https://www.smartsheet.com/content/people-process-technology

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 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’s

Links:

• https://simonsinek.com/product/start-with-why/
• https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action?language=en

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