Proactivizer: Transforming Existing Verification Tools into Efficient Solutions for Runtime Security Enforcement

Abstract

Security verification plays a vital role in providing users the needed security assurance in many applications. However, applying existing verification tools for runtime security enforcement may suffer from a common limitation, i.e., causing significant delay to user requests. The key reason to this limitation is that these tools are not specifically designed for runtime enforcement, especially in a dynamic and large-scale environment like clouds. In this paper, we address this issue by proposing a proactive framework, namely, Proactivizer, to transform existing verification tools into efficient solutions for runtime security enforcement. Our main idea is to leverage existing verification tools as black boxes and to proactively trigger the verification process based on dependency relationships among the events. As a proof of concept, we apply Proactivizer to several existing verification tools and integrate it with OpenStack, a popular cloud platform. We perform extensive experiments in both simulated and real cloud environments and the results demonstrate the effectiveness of Proactivizer in reducing the response time significantly (e.g., within 9 ms to verify a cloud of 100,000 VMs and up to 99.9% reduction in response time).

Appendices

A Guideline to Adapt to Other Cloud Platforms

Our solution interacts with the cloud platform (e.g., while collecting logs and intercepting runtime events) through two modules: pre-processor and interceptor. These two modules require to interpret implementation- specific event instances, and intercept runtime events. First, to interpret platform-specific event instances to generic event types, we currently maintain a mapping of the APIs from different platforms. Table 4 enlists some examples of such mappings. Second, the interception mechanism may require to be implemented for each cloud platform. In OpenStack, we leverage WSGI middleware to intercept and enforce the proactive auditing results so that compliance can be preserved. Through our preliminary study, we identified that almost all major platforms provide an option to intercept cloud events. In Amazon using AWS Lambda functions, developers can write their own code to intercept and monitor events. Google GCP introduces GCP Metrics to configure charting or alerting different critical situations. Our understanding is that our solution can be integrated to GCP as one of the metrics similarly as the dos_intercept_count metric, which intends to prevent DoS attacks. The Azure Event Grid is an event managing service from Azure to monitor and control event routing which is quite similar as our interception mechanism. Therefore, we believe that our solution can be an extension of the Azure Event Grid to proactively audit cloud events. Tables 4 and 5 represent the necessary mapping to be used for extending our approach from OpenStack to other cloud platforms. The rest modules of our solution deal with the platform-independent data, and hence, the next steps in our solution are platform-agnostic.

Table 4. Mapping event APIs from different cloud platforms to generic event types

Table 5. Interception supports to adopt our solution in major cloud platforms

B Performance of the Cache Implementation

Figure 12 illustrates the response time in case there is a cache hit (when runtime parameters is found in the implemented cache memory) and the additional delay for a cache miss (when requested parameters is not in the cache memory) for Patron and Congress, respectively. In Fig. 12(a), for different sizes of cache, we observe a quasi constant response time (which is less than one millisecond) for Patron with our framework, and an additional delay for a cache miss of up to four milliseconds. Figure 12(b) shows the results of similar experiment for Congress with our framework; where a cache hit causes further improvement on the response time, but a cache miss may cause up to 137 ms of delay. Overall the results show the response time can be even less than one millisecond at the best case, and at the worst case (when the prediction is incorrect), Proactivizer will have no effect on those applications. However, for most cases (around 85.5% time), Proactivizer can keep their response time within ten milliseconds.

Fig. 12.

The average response time for a cache hit and delay for a cache miss for (a) Patron (access control tool) and (b) Congress (Datalog solver), while varying the size of the cache and number of VMs, respectively