Many breaches start with an “own goal,” an easily preventable misconfiguration or oversight that scores a goal for the opponents rather than for your team. In platform-as-a-service (PaaS) applications, the risk profile of the application can lure organizations into a false sense of security. While overall risk to the organization can be lowered, and new capabilities otherwise unavailable can be unlocked, developing a PaaS application requires careful consideration to avoid leaking your data and making the task of your opponent easier.
PaaS integrated applications are nearly always multistep service architectures, leaving behind the simplicity of yesterday’s three-tier presentation/business/data logic applications and basic model-view-controller architectures. While many of these functional patterns are carried forward into modern applications—like separating presentation functions from the modeled representation of a data object—the PaaS application is nearly always a combination of linear and non-linear chains of data, transformation, and handoffs.
As a simple example, consider a user request to generate a snapshot of some kind of data, like a website. They make the request through a simple portal. The request would start a serverless application, which applies basic logic, completes information validation, and builds the request. The work goes into a queue—another PaaS component. A serverless application figures out the full list of work that needs to be completed and puts those actions in a list. Each of these gets picked up and completed to build the data package, which is finally captured by another serverless application to an output file, with another handoff to the publishing location(s), like a storage bucket.
Planning data interactions and the exposure at each step in the passing process is critical to the application’s integrity. The complexity of PaaS is that the team must consider threats both for each script/step at a basic level individually as well as holistically for the data stores in the application. What if I could find an exploit in one of the steps to arbitrarily start dumping data? What if I found a way to simply output more data unexpectedly than it was designed to do? What if I found a way to inject data instead, corrupting and harming rather than stealing?
The familiar threats of web applications are present, and yet our defensive posture is shaped by which elements of the applications we can see and which we cannot. Traditional edge and infrastructure indicators are replaced by a focus on how we constructed the application and how to use cloud service provider (CSP) logging together with our instrumentation to gain a more holistic picture.
In development of the overall application, the process architecture is as important as the integrity of individual technical components. The team leadership of the application development should consider insider, CSP, and external threats, and consider questions like:
- Who can modify the configuration?
- How is it audited? Logged? Who monitors?
- How do you discover rogue elements?
- How are we separating development and production?
- Do we have a strategy to manage exposure for updates through blue/green deployment?
- Have we considered the larger CSP environment configuration to eliminate public management endpoints?
- Should I use third-party tools to protect access to the cloud development and production environment’s management plane, such as a cloud access broker, together with cloud environmental tools to enumerate accounts and scan for common errors?
In the PaaS application construction, the integrity of basic code quality is magnified. The APIs and/or the initiation processes of serverless steps are the gateway to the data and other functions in the code. Development operations (DevOps) security should use available sources and tools to help protect the environment as new code is developed and deployed. These are a few ways to get your DevOps team started:
- Use the OWASP REST Security Cheat Sheet for APIs and code making calls to other services directly.
- Consider deploying tools from your CSP, such as the AWS Well-Architected Tool on a regular basis.
- Use wrappers and tie-ins to the CSP’s PaaS application, such as AWS Lambda Layers to identify critical operational steps and use them to implement key security checks.
- Use integrated automated fuzzing/static test tools to discover common missteps in code configuration early and address them as part of code updates.
- Consider accountability expectations for your development team. How are team members encouraged to remain owners of code quality? What checks are necessary to reduce your risk before considering a user story or a specific implementation complete?
The data retained, managed, and created by PaaS applications has a critical value—without it, few PaaS applications would exist. Development teams need to work with larger security functions to consider the privacy requirements and security implications and to make decisions on things like data classification and potential threats. These threats can be managed, but the specific countermeasures often require a coordinated implementation between the code to access data stores, the data store configuration itself, and the dedicated development of separate data integrity functions, as well as a disaster recovery strategy.
Based on the identified risks, your team may want to consider:
- Using data management steps to reduce the threat of data leakage (such as limiting the amount of data or records which can be returned in a given application request).
- Looking at counters, code instrumentation, and account-based controls to detect and limit abuse.
- Associating requests to specific accounts/application users in your logging mechanisms to create a trail for troubleshooting and investigation.
- Recording data access logging to a hardened data store, and if the sensitivity/risk of the data store requires, transition logs to an isolated account or repository.
- Asking your development team what the business impact of corrupting the value of your analysis, or the integrity of the data set itself might be, for example, by an otherwise authorized user injecting trash?
PaaS applications offer compelling value, economies of scale, new capabilities, and access to advanced processing otherwise out of reach for many organizations in traditional infrastructure. These services require careful planning, coordination of security operations and development teams, and a commitment to architecture in both technical development and managing risk through organizational process. Failing to consider and invest in these areas while rushing headlong into new PaaS tools might lead your team to discover that your app has sprung a leak!
The post Our PaaS App Sprung a Leak appeared first on McAfee Blogs.
Article Link: https://securingtomorrow.mcafee.com/business/cloud-security/our-paas-app-sprung-a-leak/