Defining the “Full Stack” in Full Stack Security Observability
Here at Threat Stack, we’ve been talking a lot about security observability recently (check out this article and whitepaper). When you design and monitor your systems for security observability, you reduce risk and minimize the likelihood and potential impact of a security breach.
But in the same way that you’d never invest in locks and alarms for the windows of your house while leaving the doors wide open, you can’t protect your business by focusing security observability on a single perimeter only. Security observability delivers value when it’s applied throughout the entire system. We call this Full Stack Security Observability. But what, exactly, is the “full stack?”
When people hear the term “application stack” or “technology stack,” they typically picture some simply labelled blocks sitting on top of other blocks. The OSI model illustrates seven “layers” spanning from physical through application. The n-tier application stack typically places a database beneath a business logic tier, web tier, and client tier, and so on. And there are solution stacks like LAMP which builds Python and MySQL atop Apache on Linux.
To address the security of their systems, some organizations build their plan on these models. They draw a padlock on each box and note what secures that tier. Simple. But while these models can be helpful to visualize the static composition of the environment in which a solution runs — at one moment in time — they quickly fail to accurately capture cloud native infrastructure and modern architectures (such as microservices) built by modern teams using DevOps and Agile development methodologies. These stacks feature highly dynamic and ephemeral infrastructure delivered with new build and orchestration tools used by agile teams to deliver products. And they are highly iterative, in a constant loop of feedback and change, cycling in as little as hours in some cases.
You can only start to reduce security risk in these types of cloud applications when you know where to find the risks, and when to find them. That means being able to see not just up and down the tiers of the traditional technology stack, but between individual stacks isolated as services, across the lifecycle of each — from development through testing and into operation — and into the roles on the team responsible across them all.
To reduce security risk in cloud applications, then, you need insight into three planes: Tiers, Time, and Team. This is Full Stack Security Observability. If you understand the intersection points of these three planes, you can build for observability, which lets you understand the overall security health of your systems, detect abnormalities, and investigate security incidents quickly and thoroughly.
The Three “Planes” of Full Stack Security Observability
1. Tier
This is the closest to what is typically thought of as an application or technology stack. It represents the parts of the solution, generally stacked in order of abstraction: the higher in the stack, the more abstracted the component. In a modern cloud application, for example, the bottom component might be the various cloud services — AWS EC2 and EKS, Google App Engine and GKE, etc. Those might support backend app services like databases and application runtimes. And client-side functionality might be at the top. Some additional components are often overlooked when it comes to security: for example, the control plane for the cloud service where system users and their permissions are managed, or secrets management for the many SSH keys, certs, and other configuration secrets that are needed to build and deploy apps.
2. Time
The notion of a software development lifecycle, or SDLC, is familiar. But security risks (and the steps needed to reduce them) change throughout the cycle. And in cloud-native environments, those cycles move fast. According to the 2018 DORA State of DevOps report, high-performing DevOps teams have 46X more frequent code deploys than low-performing teams.
The steps you take to reduce risk from application vulnerabilities (application tier) will be different when the app is under development versus when it’s running in production (time). The CI/CD pipeline itself can be exploited in a number of ways — and ultimately compromise the integrity of what is moving through the process. And various types of high-value information, such as infrastructure keys and code signing keys, are present at different times. (See the Threat Stack Whitepaper, Build-Time Security: Securing Your CI/CD Pipeline, for more on this topic.)
3. Team
The final plane to consider consists of the team involved. Oftentimes, each point in time and each tier will have a separate owner, spread across IT, engineering, and operations organizations. And different team members each have distinct roles to play in reducing security risk. In organizations using microservices architecture, this can be even more complex when polyglot teams develop their services in relative isolation and on different schedules.
Full Stack Security Observability focuses on key intersections of these three planes. What does each individual team member need to know about each part of the application tier at each point of time in the development and operation lifecycle? What can be monitored? And what actions can be taken to reduce security risks at each? For example, what does a security pro (team) need to know about container images (tier) spinning up by the CI process (time)? Or what can a developer (team) do to reduce risk from third-party components (tier) during development (time)?
Full Stack Security Observability Enables You To . . .
Full Stack Security Observability enables you to modernize your testing, monitoring, and controls to fit within modern cloud-native environments and enable you to proactively reduce risk. It is an ongoing approach to shifting from a reactive to a proactive security posture by informing how you design, monitor, and continually improve your systems across the full stack of tiers, time, and teams.
The post Defining the “Full Stack” in Full Stack Security Observability appeared first on Threat Stack.
*** This is a Security Bloggers Network syndicated blog from Blog – Threat Stack authored by Tim Buntel. Read the original post at: https://www.threatstack.com/blog/defining-the-full-stack-in-full-stack-security-observability
