Policy As Code
Human-less Attestation of your Software Product
Most of the time, human intervention is required wherever security, quality control, and compliance are required. However, there are governance approaches that allow us to automate all of the previously mentioned steps. We’re going to talk about something very interesting today; I’m not sure if you’ve heard of it, but we’ll talk about Policy As Code and see a few examples, especially with respect to Mobiles. Let’s start…🏃🏼➡️
I accidentally broke my macbook 😭, and after getting new one, I was considering what to share with you guys. I recently finished reading about PAC, so I thought I’d share it with you all.
What is Policy As Code 🧐
It is a set of automated procedures designed to ensure the quality of your apps’ software development life cycles. It involves using code, as opposed to human procedures, to define and enforce infrastructure, security, and compliance standards.
Why does it matter?
Errors and inconsistencies may happen when policies are enforced by humans, particularly when applications and infrastructure become more sophisticated. Practically speaking, if one individual leaves your team, a new hire might need to go through a learning curve in order to perform on par with the departing employee. However, PAC can provide certain automated processes that require little knowledge of the entire infrastructure, allowing you to carry out all tasks with the same level of proficiency. There are still more advantages, which we shall discuss in the conclusion, along with some drawbacks 😁
Types
In terms of how they are defined and implemented, we can say PAC is of two types.
There are types of policies depending on the context and requirements of the system or application being managed i.e infrastructure, security, compliance etc; But we will only focus in terms of how they are defined and implemented which we can cover by their way of implementation.
Static Policies
At the moment of deployment, static policies are established and implemented as code. Until the next deployment cycle, the policy code typically stays the same after it is deployed. Typically, scripts or configuration files are used to define static policies.
Dynamic Policies
You can change and enforce policies dynamically during runtime by using dynamic policies as code. APIs can be used to change dynamic policies, which are often written in code inside the application or service. Organizations can adjust to shifting needs and threats while an app is operating because of the flexibility and responsiveness of dynamic policies, which can be more responsive than static policies.
Additionally, I’ll work to bring it closer in the Concept of mobile apps so that mobile background people can relate to that one.
You can select and configure your PaC using a variety of available tools. Easy of use, compatibility with your current stack, support for the rules and compliance frameworks that are important to you and your company, and the degree of automation and integration you need are all important considerations when choosing a PaC solution.
When & Where
It is necessary to incorporate PaC into your development process after you have chosen a tool and established your policies. This may be leveraging PaC tools to monitor and enforce rules in production at run-time or designing your CI/CD pipeline to validate policies at build time and integrate policy checks into your testing process.
Language type
If your PaC involves several platforms, you’ll need to select a higher-level language, such as Python or YML. However, any language you decide, it must be freely interchangeable throughout all of your components, including the web, mobile apps, and any other platforms you wish to allow PAC for.
Let’s now examine the following example:
Here is an example of dynamic PAC, in which a mobile app’s yml file contains defined keys and values that can be changed while the app is executing through API responses.
# Geolocation-based Promotion Policy
# Define a list of allowed countries for promotions
allowed_countries:
- United States
# Add more countries as needed
# Define a list of allowed regions within each country
allowed_regions:
United States:
- Texas
- North Carolina
- Pennsylvania
# Define a default promotion for users outside the allowed countries or regions
default_promotion:
message: "Sorry, promotions are not available in your location at this time."Explanation of Policy:
- Allowed Countries: This section defines a list of countries where promotions are available. Users located in these countries are eligible to see promotions.
- Allowed Regions: This specifies a list of regions within each country where promotions are available. This allows for finer-grained control over promotions based on geographic location.
- Default Promotion: Specifies a default promotion message for users located outside the allowed countries or regions. This ensures that users who are not eligible for promotions receive an appropriate message.
Implementation of Policy:
To implement this policy in your application, you would need to:
- Retrieve the user’s geolocation information (such as their country or region) either directly from the device’s GPS or by using a geolocation service.
- Compare the user’s geolocation with the allowed countries and regions defined in the policy.
- If the user’s geolocation matches an allowed country and region, display the relevant promotions to the user.
- If the user’s geolocation does not match any allowed country or region, display the default promotion message specified in the policy.
By implementing this geolocation-based promotion policy, you can ensure that promotions are only displayed to users who are located in the specified countries and regions,
Check out this further example of setting up SOS for a user who appears to be engaging in questionable activities (quite useful for banking domain apps): The user may be using different IP addresses or repeatedly logging in to certain APIs. The user is changing their security question or other settings, such as their transaction notification. This may indicate that the user is not a legitimate user or does not know how to use the app, in which case we can log them out once SOS is activated.However, in this case, PAC will be activated on both sides. Server-side policies will monitor responses and send responses in accordance with mobile policies, allowing mobile to force users to log out.
---
max_hit_to_server_in_a_min:
- 15
is_security_setting_changed_by_usr:
- false
enable_sos:
is_ip_address_changed:
- false
is_device_jail_broken:
- false
default_message:
message: "User is not authenticated; please contact the support team."The above data is arbitrary and does not accurately represent the use cases. The actual implementation may differ greatly from the example given above.
The aforementioned regulations are instances of dynamic policies. Static policies, on the other hand, can include encryption mechanisms, some kind of logging, or an occasional compliance check.
And here are its few advantages and disadvantages:
That’s all there is to it. I’ve attempted to provide a very small amount of knowledge, which may be useful to anyone who wants to include PAC in mobile apps but is uncertain where to begin. This could be a small beginning for them, in my opinion.
And that’s it. Thank you for reading my post. I really appreciate your time. If you think it’s helpful, please clap or comment. And in the following one, I see you. 🙌
