By Edward Amoroso, TAG Cyber and Sharon Vardi, Prevoty
During a recent technical discussion between TAG Cyber and Prevoty, the challenge of explaining autonomous application protection prompted analogies with autonomous cars. This parallel was useful because most people, even technical professionals, tend to be more familiar with vehicles than with software application development.
Furthermore, we posited that even those of us with no direct autonomous car experience would recognize the risks associated with self-driving cars more readily than those related to software applications. We wanted to determine if this analogy would hold up to greater scrutiny, so we decided to compare their most important respective security characteristics. What we found was sufficient correlation between three specific protection requirements to justify this note, which we hope will help application designers and security leaders.
Autonomous Cars, an Analogy to Application Security
Autonomous cars do not need humans for navigation. Instead, they collect sensory data from their surroundings to determine the best path forward. Autonomous cars, like software applications, must be aware of other cars, weather, pedestrians, and other obstacles, and make real-time decisions based on probable outcomes. To mitigate self-driving risk, determinations must be made by the vehicle in real time, based on what is happening locally. This means that a self-driving car cannot rely solely on remote management, but rather must be self-aware of what's happening in the vicinity to react properly.
Many of the characteristics of vehicle self-navigation also exist for software applications. That is, when a malicious actor begins to attack an application, real-time decisions, such as blocking, must be made immediately to prevent cascading risk. As with cars, relying solely on external services to make these risk decisions can lead to deficiencies in the accuracy and timeliness of application security. Instead, autonomous protection of applications – the software equivalent of self-driving – turns out to be the optimal means for ensuring real-time secure operation.
Autonomous Car Security
So, what are the security requirements that enable self-driving cars to make decisions that protect the vehicle and its passengers? Furthermore, how do software security designers build in these critical capabilities? While it would be easy to develop multi-page lists, we believe the primary security requirements – the ones most directly related to the mission of an autonomous car – include the following three functional areas:
- Authenticity of Command and Sensory Environment – Autonomous vehicles rely on commands from on-board and network-resident systems, as well as from collected sensory data. The authenticity of this data must be assured to prevent hijacking, spoofing, and other attempts to create an incorrect view of surroundings. For example, parents placing kids into a self-driving car must know that hackers cannot spoof telemetry, such as the presence of a fake obstacle.
- Accuracy and Effectiveness of Protection Algorithms – The algorithms used to protect autonomous cars must rely on the domain expertise of developers. For example, security signatures and behavioral thresholds that require security response for cars can only be determined by engineers who know the internals of the automobile. This helps explain why off-the-shelf IT security tools may not be well-suited to autonomous cars. Protection algorithms must come from car experts, not security engineers with general knowledge.
- Integrity of On-Board Operational Controls – The need to ensure the integrity of on-board operational controls for an autonomous vehicle should be obvious. Trusted execution, behavioral monitoring, and fail-safe operation are example controls that reduce the likelihood of malicious tampering. One might argue that the integrity of on-board operation is the most important control area, because it so directly affects mission. A virus that degrades the accuracy of autonomous steering, for example, is totally unacceptable in any autonomous car.
Clearly, a deliberate cyberattack targeting any of these security controls can result in mission failure, including potential loss of life. This contrasts with less critical security threats such as vehicle location hacking, on-board entertainment system tampering, or highway toll payment fraud. Nevertheless, best-in-class controls for autonomous vehicles must employ all protection requirements for all aspects of the car and its occupants. The analogy to application security seems to follow directly from these autonomous car requirement categories. That is, we can easily characterize the autonomous protection of hosted software applications using a similar framework.
Autonomous Application Security
Autonomous application security is accomplished without real-time reliance on humans. The method instead instruments software applications with agents for self-protection. People certainly perform the installation, administration, and operational interpretation of collected telemetry, but the application protects itself during runtime. Relying solely on information that is acquired by the agent in real time while the application is serving users in production allows for immediate mitigation of risk. Such agents can leverage a variety of different technologies, including grammar-based approaches. The security requirements that must be addressed – and you will notice the parallels to autonomous car protection – are as follows:
- Authenticity of Application Run-time Environment – Applications must have the ability to determine the correctness and authenticity of collected sensory data. Without such control, malware might try to fool the autonomous protections with bogus data. Such attacks are designed to lead the security mechanisms astray by offering phony information, rather than by directly corrupting the control operation. Validation mechanisms using strong authentication must therefore be employed to ensure proper environmental telemetry collection.
- Accuracy and Effectiveness of Protection Algorithms – The effectiveness of the algorithms for self-protecting applications will correlate with the domain expertise of the developer. Proper autonomous protection requires predefined signatures, behavioral analytic patterns, and machine learning that are based on domain knowledge of the specific application. Thus, just as with cars, the best protection algorithms come from domain experts rather than generalists.
- Integrity of Application Security Controls – The need for integrity assurance of runtime controls in autonomous application protection is obvious, since the automation will require bounds checking to ensure proper security. If the autonomous security is corrupted, then clearly the mission of self-protection will be jeopardized.
As with autonomous cars, self-protecting applications are reliant not only on the control areas listed above, but also on a plethora of additional factors such as simplicity of design, elegance of architecture, and experienced system administration. Nevertheless, it is the above three factors that most directly inform the analogy between self-protecting cars and self-protecting application software.
Design Implications
One useful design implication from this analogy is that good ideas in one area might be reused or modified in another. This is welcome, because autonomous control in both areas is likely to increase dramatically in the coming years – albeit for different reasons. With this growth will come improved security R&D that can be shared respectively.
Another useful design implication is that the education required to help enterprise managers, executives, and practitioners can benefit from the analogy. As we found during our own technical discussions, the analogy helped spur more effective technical exchanges, because all involved could share a common underlying computation model.
Finally, this analogy will help create the supporting assurance, compliance, and regulatory controls required in each area. This does not, however, necessarily mean an increase in these requirements, but rather the comparative experiences might help optimize the obligations for application developers, owners, vendors, and users.
