Information security programs frequently begin with the best of intentions: to coolly analyze risks and then to design, prescribe, and deploy security solutions for developers. The reality is that information security, writ large, usually devolves into a taillight-chasing exercise. These taillights are the vapor trails left by the latest breach or big name vulnerability.
On the Internet, information security has been playing a decades-long game of catch up. Developers innovate and the security teams rush behind to clean up as many vulnerabilities as they can find and solve. Yet, this fact has not clobbered businesses, many of whom are still able to carve out very profitable niches despite the threats on the Internet.
One of the reasons that the catchup game on web security has not proven fatal is the pace of development. When the web began in the mid-1990s, the security pros of that era quickly realized that they needed to ensure that they could separate the good stuff in the enterprise from the bad stuff on the web. To do this, they used a network firewall and set up the famous demilitarized zone (DMZ) pattern. To secure the last mile from the web server to the browser, they used SSL:
|
Software |
Security | |
|---|---|---|
|
1995 |
CGI/PERL |
Network firewalls & SSL |
|
1997 |
JSP, ASP |
Network firewalls & SSL |
|
1998 |
EJB, DCOM |
Network firewalls & SSL |
|
1999 |
SOAP, XML |
Network firewalls & SSL |
|
2001 |
SOA, REST |
Network firewalls & SSL |
|
2003 |
Web 2.0 |
Network firewalls & SSL |
|
2007 |
Cloud Computing |
Network firewalls & SSL |
|
2009 |
Mobile |
? |
The firewalls + SSL pattern was not particularly resilient against threats such as SQL injection or cross-site scripting; however, it proved effective enough to protect the sites in the 1990s. The reason for this is that the websites in the early days were mainly brochureware. Therefore, as the developers continued to innovate dynamic websites with ASP and JSP, along with three-tier architecture, web services, and so on; the security teams had some lag time to revisit, revamp, and refresh their security services.
This is precisely what makes mobile security so dangerous. The early use cases for web apps were brochureware, and interactive databases were considered advanced (Paul Graham, the co-founder of Y Combinator, still dines out on this decades later), the net result here is that the security teams had time to catch up as early deployments were low-risk assets and as higher-risk items were added, there was some lag for the security to innovate.
In the case of mobile, it's the opposite. The early mobile use cases and apps are not low-risk, they are among the highest-risk use cases that you can imagine—mobile banking, connecting to medical devices, mobile payments, and direct access enterprise backends. The knock-on effect here is that the old information security catch up game, where the developers incrementally innovate and the security teams catch up, cannot work any longer. The move to mobile is not the developers and businesses dipping toes in the water, its jumping headlong off the diving board; security needs a fresh approach. Security teams cannot be bystanders, interested observers, or walking behind the elephant with a broom any more.
For mobile, the security teams must be the core engineers, deeply intertwingled with design, development, and deployment of the effective security capabilities.
Gunnar Peterson
Security Architect and blogger