What are Cloud Native Applications?

Cloud-native applications are built purposefully for deployment and operation in a cloud environment. They consist of small, independent microservices, such as serverless functions and containers, and utilize services that cloud providers and third-party partners provide via API, all while leveraging the cloud for automated stability, scaling, and recovery. Building cloud-native applications enable development teams to focus on implementing architectures that are optimized for how the cloud scales.

 

Request a Demo Download eBook

What are Cloud Native Applications?

Cloud-native applications Structure

Cloud-native applications have a new, distinct structure that affects how attackers approach these applications, which shifts the threat landscape. As attackers change their approach and move towards Gen VI attacks, security practitioners and developers must adjust accordingly how they defend cloud-native applications.

They need to allocate more time and resources to these new threats in order to best prevent them for their organization. Resources must be allocated strategically, but one must first understand which threats are most likely in this new threat landscape.

Types of Cloud Native Application Threats

Compute services in cloud-native applications are designed to be ephemeral and tend to have short lifespans. This is one of many attributes that makes cloud native applications inherently more secure. Attackers are unable to easily achieve long-term presence in your system and must, therefore, shift tactics. One resulting strategy is the Groundhog Day Attack in which an attacker crafts a much shorter attack that steals, for example, just a few credit card numbers, and then repeats. Attackers leverage the automatic scaling of the cloud native application to get by the ephemerality of it.

Another approach is the Upstream attack, or Poisoning the Well in which attackers aim to gain more long-term persistence in your application. Cloud-native applications tend to comprise many modules and libraries. A single serverless function could include tens of thousands of lines of code from a variety of sources other than the work of your developers. Attackers work to include malicious code in common projects. Then, after poisoning the well, the malicious code in your cloud applications can call home, get instructions, and wreak havoc.

How to Secure Cloud Native Applications

Fortunately, cloud native applications tend to be harder to attack. But as a new type of architecture, they present new security challenges and developers must act to mitigate risk. The following are some best practices to secure cloud-native applications:

  1. Apply Perimeter Security at the function levelThe fragmentation of your application to smaller components that are callable, coupled with the use of event-based triggers from diverse sources (such as storage, message queues, and databases) means attackers have more targets and more attack vectors.

    In addition to ensuring your Web API and Application Protection (WAAP) services are advanced to address next generation requirements, another cloud native security best practice is to apply perimeter security at the function level as well. Pay particular attention to functions that are triggered by a different source type.

  2. Craft Suitable, Minimal Roles for Each FunctionYou must establish roles for the many interactions between your cloud native resources. The ability to assign a unique set of permissions to each serverless function provides an excellent opportunity to enhance AppSec even further.

    When you do IAM at the granularity of functions, IAM becomes an AppSec tool. Spend time crafting suitable, minimal roles for each of your functions. Additionally, ensure that each of your functions executes with the smallest viable set of privileges, so the damage from any holes that slip through is minimal.

  3. Secure Application DependenciesFunctions often include dependencies, pulled in from npm (Node.js), PyPI (Python), Maven (Java) or other relevant repositories. Securing application dependencies requires access to a good database and automated tools including native orchestration tools to trigger application security during development,-. Continuously running these tools prevents new vulnerable packages from being used and get alerted to newly disclosed issues.
  4. Make Security is Everyone’s Problem

    Forge close partnerships between developers, DevOps, and AppSec teams. Find the balance where developers don t own security, but they are not absolved from responsibility either – secure coding as an example. Mark Collier, COO of the OpenStack Foundation was quoted in an article in Bloomberg saying, “the shift from monolithic/waterfall to agile/DevOps is more about process and organizational psychology than it is about which technologies to employ.

    This has been talked about for several years and it’s not going away anytime soon. It’s a big problem that enterprises must address and it’s going to take years to get there as it’s a generational shift in philosophy.”

    It is important for teams to bridge the gaps early, even if it feels against the normal behavior of the company DNA as cloud native requires a different approach in how organizations manage security and development. This creates a real opportunity for departments to facilitate this change and make a true impact.

 

Secure Cloud Native Applications With Check Point

Ops must create pipelines that let developers work at the speed of serverless and still deploy applications in a realistic and secure way.

These are just a few of the many items regarding security, one must think about when migrating to cloud native applications and microservervices. There are new tools designed every day to help optimize this transition and create greater visibility, observability, security, and threat prevention. For more information on how to address cloud native security, refer to the Cloud Security Solutions guide from Check Point Software.

×
  Feedback
This website uses cookies for its functionality and for analytics and marketing purposes. By continuing to use this website, you agree to the use of cookies. For more information, please read our Cookies Notice.
OK