Recently, I listened in on an IEEE-SA sponsored roundtable at the RSA Conference in San Francisco on April 22, 2015. Karen McCabe, IEEE-SA senior director, Technology Policy and International Affairs, lead a discussion on whether Application Programming Interface (API) regulation is necessary for the future of information security. Participants were Bret Hartman, VP and CTO, Security Business Group, Cisco Systems, Inc.; Cooper Quintin, staff technologist, Electronic Frontier Foundation; Monique Morrow, CTO, evangelist, New Frontiers Development and Engineering, Cisco Systems, Inc.; Hadi Narhari, chief security architect, NVIDIA; Rob Zazueta, Director Platform Strategy, Mashery (Intel); Matt McLarty, VP, The API Academy, CA Technologies; and moderator Kimball Brown, Independent Technology Consultant.
What is an Application Programmable Interface (API)? In its native form, APIs are building blocks for developers to construct programs. APIs often come in the form of a library that includes specifications for routines, data structures, object classes and variables. In other cases an API is simply a specification of remote calls exposed to the API consumers (for example, JSON and REST). These APIs are used primarily for many of the virtualized functions/service programs we are seeing on the market today. Think of a remote controlled robot on a manufacturing floor, a virtual network function in a switch or your favorite application on your cell phone that accesses the sensor on your wrist that monitors your heart or on a macroscopic scale, the billions of devices that are forecasted to exist via the Internet Of Things (IoT) and the programs to control them. All of these programs will rely on APIs in their development. Imagine if a rogue hacker tried to manipulate these programs via accessible APIs to cause harm? There lies the issue. How can this be avoided? What is the state of protection now? And where does this responsibility lie?
The panel agreed that there needs to be more education given to developers on building security into their initial designs, possibly implementing an attack tree or use case security framework from which to build. This framework should be transparent to the consumer because this structure should not impede on the go-to-market strategies that affect the bottom line. Although the panel agreed that this would be a good idea, because there are so many types of APIs, there is no standard way to implement this. As for IoT, the development environment is not like a static information technology environment where the attack points are relatively predictable. IoT environments, in many cases, will be mobile, personal and limited in memory space for which traditional security measures cannot be used. The threat model will have to be redefined, which has yet to happen. Once one is established this model should be communicated to developers as well as consumers.
Panel member also discussed a universal consortium establishing standards and if this would help the problem? The answer was a little but it would not fully address the problem, because the market pace and demand will be too fast for standardization groups to react. One thought was to develop an emerging new API platform with proper hooks and external partners buying into the model. This thought spurred an interesting conversation dealing with the integrity of the partners in the joint venture. How credible are they? This led quickly into the examples of Target, Snapchat and J.P Morgan/Chase where the weak link was the integrity of the partner and not necessarily the flaw of an API, underscoring that business partners having a stake in the level of security that is needed. This led to an interesting discussion concerning Person Area Networks (PAN) where the person becomes the API. Would a developer, consumer or human PAN bill of rights help? Again a “one-size-fits-all” constitution would be tough because every person has his or her own view of what personal security means? It would be hard for a government or business to enforce such a constitution. Businesses do not want regulation to hinder innovation or sales.
The discussion concluded with the final question of how APIs will look in 10 years? All panelists agreed that presently APIs are in a single-user mode and need to move toward a distributed model. Higher levels of SDKs need to be implemented. APIs should have a different paradigm for deployment such that devices, services and systems govern themselves. For example, applications should automatically inform the API what it can and cannot do during processes. For IoT, this method will allow better integration between devices, reduce human regulation policies and thus optimize security.
.jpg)
