Security is moving to the application layer. Once, the design of secure operating
systems and Internet security protocols were the main foundations of information
security. According to the then predominant mood, IT systems could be used
securely once secure infrastructures were in place. Remnants of this era can still
be found in claims that one MUST secure operating systems or the Internet to
be able to securely use today’s critical IT infrastructures.
We observe, however, that security mechanisms in end systems are moving
to the application layer of the software stack. The reference monitor has moved
from the operating into web pages (Figure 3). Security components at upper
layers may be effective without support from below. This works as long as direct
access to the lower layers need not be considered as a threat. In parallel, communications
security mechanisms have been moving to the application layer of
the protocol stack. At the point where end system security and communications
security meet, i.e. in the software components running network protocols, we
have seen shared secrets moved up to the application layer to defend against
attacks at the infrastructure layer (Section 3.3), contrary to the conventional
security strategy that tries to embed secrets at a layer as low as possible, e.g. in
tamper resistant hardware.
The security services expected from the infrastructure may thus change over
time. We can also observe that our view of what constitutes the infrastructure
may change over time. The web browser that started as a new application has
today become an essential infrastructure component for Web services.
The Internet is a critical infrastructure because it is the platform for critical
applications. Our primary challenge is the protection of these applications. Security
services provided by the infrastructure may help in this cause, but trust
in these services may also be misplaced when application writers misunderstand
the security properties actually guaranteed.
It is a trivial observation on security engineering that defenders ought to
know where their systems will be attacked. When attacks are launched via the
interface of web applications, the first line of defence should be at that layer.
Attacks may be directed against the application, e.g. fraudulent bank transfers
in an e-banking application. Application-level access control necessarily relates
to principals meaningful for the application. There may be mappings from those
principals to principals known to the infrastructure so that security services from
the infrastructure can support application security. However, in every instance
we must verify that it is not possible for attackers to redefine the binding between
principal names at different system layers. We may thus surmise that it is more
likely to find access control solutions at the application layer, as borne out by
our earlier observations on reference monitors. In this respect, we have secure
applications without a security infrastructure.
Attacks may be directed against the end system hosting the application. Software
vulnerabilities in an application may present the attacker with an opportunity
to step down into the infrastructure. Although software security issues
could be addressed in each application, it would be desirable to have a ‘secure’
computing infrastructure, i.e. an infrastructure that can deal with malformed inputs
forwarded via the applications. In this respect, critical applications benefit
from a computing infrastructure that can protect its own execution integrity.
The primary property required fromthe communications infrastructure is availability.
Security services such as confidentiality, integrity, or authenticity may or
may not be provided by the communications infrastructure. The relativemerits of
delivering these services in the various layers of the network stack have been discussed
extensively in the research literature. The most relevant issue for critical
applications are the choice of relevant principals that can serve as logical endpoints
for application layer transactions, and the authentication of those principals.
We leave the reader with a final challenge. When security is moving to the
application layer, responsibility for security will increasingly rest with application
writers and with end users. At this point in time, neither of the two communities
is well prepared to take on this task, but nor has security research made much
progress in explaining to non-experts the implications of security decisions.
References
1. Arends, R., Austein, R., Larson, M., Massey, D., Rose, S.: DNS security introduction
and requirements. RFC 4033 (March 2005)
2. Arends, R., Austein, R., Larson, M., Massey, D., Rose, S.: Protocol modifications
for the DNS security extensions. RFC 4035 (March 2005)
3. Arends, R., Austein, R., Larson, M., Massey, D., Rose, S.: Resource records for the
DNS security extensions. RFC 4034 (March 2005)
4. Burns, J.: Cross site reference forgery. Technical report, Information Security Partners,
LLC, Version 1.1 (2005)
5. CERT Coordination Center.Malicious HTML tags embedded in client web requests
(2000), http://www.cert.org/advisories/CA-2000-02.html
6. Dean, D., Felten, E.W., Wallach, D.S.: Java security: from HotJava to Netscape
and beyond. In: Proceedings of the 1996 IEEE Symposium on Security and Privacy,
pp. 190–200 (1996)
7. Dierks, T., Rescorla, E.: The TLS protocol – version 1.2, RFC 5246 (August 2008)
8. Gong, L., Dageforde, M., Ellison, G.W.: Inside Java 2 Platform Security, 2nd edn.
Addison-Wesley, Reading (2003)
9. Howard,M., LeBlanc, D.:Writing Secure Code, 2nd edn.Microsoft Press, Redmond
(2002)
10. Jackson, C., Barth, A., Bortz, A., Shao, W., Boneh, D.: Protecting browsers from
DNS rebinding attacks. In: Proceedings of the 14th ACM Conference on Computer
and Communications Security, pp. 421–431 (2007)
11. Kent, S., Seo, K.: Security architecture for the Internet protocol, RFC 4301 (December
2005)
12. Marsh, R., Dispensa, S.: Renegotiating TLS. Technical report, PhoneFactor Inc.,
Malvern (November 2009)
13. One, A.: Smashing the stack for fun and profit. Phrack Magazine 49 (1996)
14. Oppliger, R., Hauser, R., Basin, D.A.: SSL/TLS session-aware user authentication.
IEEE Computer 41(3), 59–65 (2008)
15. Rescorla, E., Ray, M., Dispensa, S., Oskov, N.: Transport layer security (TLS)
renegotiation indication extension, RFC 5746 (February 2010)
