The solution or the idea in this post can be commercialized by security product vendors or entrepreneurs. Even though this solution is built to protect Azure Web Apps, a fully managed “Platform as a Service” (PaaS), but the ideas can be applied to build solution in other public clouds like AWS or Google.
Every company on the planet has some kind of SIEM at their disposal and they are ingesting data into their SIEM of choice religiously. What’s the value of the data if no one is utilizing them intelligently? Another question, what’s the point of moving the raw data from capable cloud environment to on premise SIEM and do nothing with it? Let’s explore how to leverage cloud native capabilities to build a solution that is intelligent, less complex, less costly, secure and runs automatically.
It’s a good idea to define the problem statements before jumping on to a solution. Our web applications (api, blog, front-end) are deployed as WebApp under App Services plan in Azure cloud and they are publicly available by design. The problem is, bad actors are continuously probing the sites and exploring loopholes (vulnerabilities) to exploit. Application diagnostics are enabled and we can clearly see they (the bad actors) have no interest in typical business functions. They are doing surveillance operations to find weakness in applications and making us pay for the compute. As a CISO, we would like to deny those bad actors access to our web applications and stop them at the network layer before they can reach out to the applications, and we would like to stop them in near real-time.
As mentioned in the problem statement, web applications are configured to collect diagnostic logs. Those logs are stored in Azure Log Analytics Workspaces, a SaaS and less costly storage option. This data is our goldmine of intelligence if we can make use of it. We can clearly see the usage patterns and we can build rules to identify the malicious intents or behaviors.
Okay, we got the data and we got the actionable intelligence. We can build the solution using Azure native capabilities without leaving the cloud. Technologies and services used to build this solution-
- Azure Logic App ( Serverless, PaaS)
- Azure Log Analytics Workspace (SaaS)
- Azure Storage Account (store unstructured data)
- Azure Function (Serverless, PaaS)
- Azure Key Vault (PaaS, secure and password-less access to credentials)
- Azure SDK for .Net (use the power of .Net and C#)
- .Net Core 3.1
- Postman, for testing (can you write codes completely free of bugs?)
We are going to use Azure Logic App to start the flow based on suitable trigger. Time trigger is one of the simplest trigger that we can use. First, we would query the log analytics workspace data and get the results. Next, we would stage the results to storage account table, a very low cost storage option. We could have done some more steps in Logic App but it’s not suitable for complex logic. We can make use of Azure Function, a serverless solution and call the function from Logic App. Why pay for something you would not use 7×24? No need to patch a server. Worried about audit and monitoring? You can leverage azure native services, just enable the logging.
Azure Function is where we have the intelligent business logic to determine if a caller should be blocked. We would use a persistent storage table to keep track of the bad callers and allow exceptions (if needed). Once we have a list of IP or CIDR considered bad actors, we would add them to Network Access Restrictions.
Azure SDK for .Net can make the job much easy to interact with Azure Resource Manager. We can add/update access restrictions with a single call. Can you imagine how many calls you have to make if you were to use PowerShell!
As security best practice, we would use managed identity to run Azure Function and configure RBAC to allow access to other resources including access to Key Vault. We can’t use managed identity for all resources and we have to use Service Principal for those scenarios. We would store the service principal credentials in Azure Key Vault and use Azure Function managed identity to pull the credentials at runtime without having to store any credentials in configuration file. This is very similar to AWS instance role profile, just for the education, if you are not too familiar with Azure.
Compliance, Audit and Monitoring are important non-functional requirements. Does this solution comply with security? Does it maintain logs of activities those can be audited? How do we monitor exceptions and debug in the case of failures? The short answer is yes to all three. Security is a shared responsibility in the cloud between cloud provider (Azure) and the customer. As customer, we have to do our part.
- Data is secure in transit (HTTPS) and at REST. Storage account is encrypted with encryption key.
- Service principal used to manage Azure Resources via .Net SDK requires credentials and those credentials are stored at Key Vault.
- Function app uses Managed Identity to get credentials from Key vault at runtime. No password to store anywhere.
- Key Vault access log is being monitored.
- Diagnostics are enabled on Azure services and logs are going into log analytic workspace for monitoring.
- This solution runs on auto pilot and blocks the bad behaviors.
About the Author
Hands-on Architect with over 20 years of proven track record of delivering mission critical technology solutions to solve business problems. Work in partnership with cross functional teams while engaging and managing stakeholder’s relationships with internal and external customer bases. I am passionate about Information/Cloud Security and Cloud Compliance, always looking for opportunities to minimize security risks and to comply with regulations.
As a cross-domain architect, my hands-on experience extends to many domains including Application Architecture, Enterprise Architecture, Information Security Architecture, Cloud Architecture and Cloud Security Architecture. Sorry, I can’t write software drivers! Love playing volleyball.
Feel free to connect with me via LinkedIn profile.