Home Features Why the OSI Model Isn’t Enough for Application Security

Why the OSI Model Isn’t Enough for Application Security

776
0
SHARE
Application Security
SHARE

For modern business, application security is an essential concern. Every company uses a variety of web, software, and mobile applications in order to serve customers and execute internal functions. Unfortunately, far too many of these applications are subject to critical vulnerabilities as a result of insecure coding practices, flaws in third-party libraries, and changes in the cybersecurity threat landscape.

Contributed by John Adams, Chief Executive Officer of Waratek

The effects of web application vulnerabilities have been tumultuous and widespread. We’ve seen huge global corporations fall victim to a single vulnerability with disastrous results. Equifax remains the poster child for application security awareness. The original September 2017 breach occurred when a vulnerability in the Apache Struts tool (used by numerous corporations and government organizations) was compromised by hackers. By the time the breach was discovered, the personal data of 143 million Equifax customers was accessed. A settlement with state and federal investigations could ultimately cost the company as much as US$700 million dollars. Meanwhile, more than 200,000 people have already signed a petition against the deal demanding Equifax face stronger accountability.

Equifax is not the only company to fall victim to a web application vulnerability. The list of victims crosses a wide array of industries including tech, financial and education, among others, with names like Facebook, Capital One and Georgia Tech making headlines for large-scale breaches.

If incidents like this can happen at this level, all businesses should be aware that they too could become victims of an application breach. The warning signs are all there. Research shows that 71 percent of applications in product contains at least one high-severity application flaw, with the average number of high-severity flaws in production applications being five. With numerous glaring vulnerabilities, it’s no wonder that web applications remain the primary target for attackers.

So what can be done to protect businesses from falling victim to web application breaches? Perhaps a new path forward is needed. Current solutions for keeping applications secure have been developed by the network engineering community, not the application engineering community itself. In fact, far too many companies have little or no application security at all—opting instead to deploy network security controls around the application – essentially perimeter protection.

This may be due, in part, because many vendors and companies design their security posture around the Open Standard Interconnection model (OSI) model. Popularized in the mid-’80s by the International Standards Organization (ISO), OSI is a conceptual model to promote interoperability between computing systems. This model sets out a construct of standard network protocols divided into seven layers that still govern how all internal and external networks communicate and function, including how they are secured.

The OSI Networking Model

The OSI networking model describes how applications exchange information over a network by separating these communications into seven different “layers.” While each layer is independently developed, the OSI model anticipates that each layer only communicates with the layer above and below it as information passes through the layers.

According to the OSI model, the seven layers of networking are:

  1. Physical layer: This layer deals with the transmission of electrical signals across different physical devices.
  2. Datalink layer: This layer handles the encoding, decoding, and logical organization of bits into data packets.
  3. Network layer: This layer moves data throughout the network by selecting the appropriate route and forwarding the data.
  4. Transport layer: This layer defines the protocols and port numbers that hosts on the network use to communicate.
  5. Session layer: This layer manages the connection between different systems (known as a session).
  6. Presentation layer: This layer translates data between the application and the network, performing functions such as encryption, compression, and string conversion.
  7. Application layer: This layer specifies how users interact with the data on the network through the form of interfaces and protocols. 

Under the OSI model, Layer Seven puts security closest to the end-user as a transaction begins and ends its journey. While the theory makes sense, the reality is this approach increasingly does not work. When the network packet leaves Layer 7 and enters the application, the source code of the application takes over and this source code is rife with vulnerabilities.

Various network security professionals have suggested adding a Layer 8, 9, or even 10 on top of the existing OSI model. These terms are often used to emphasize the importance of a strong “security culture” at the level of the individual or the organization, as well as the need for compliance with all applicable laws and regulations.

Today’s threat landscape is one of the sophisticated attacks as well as hyperconnected infrastructure and applications, this means that the attack surface has been expanded well beyond the network.

Since the OSI model only allows for network-based security controls, application code like open source libraries, APIs, and business logic are treated as security afterthoughts rather than the root cause of security problems. If organizations use only the OSI model for their security program, they risk building a wall around their proverbial fortress but leaving the front door unlocked.

Layer 8 – Oh, the humanity!

While not official, Layer 8 (and sometimes 9 and 10) is often referred to as the Human Layer. This is the layer where people become part of the communication structure. This layer has been used to reference points of failure that result from people, such as organizational compliance weaknesses or user negligence. While not intentional, layer 8 could also include developers when they mistakenly introduce application vulnerabilities during the development lifecycle.

Without official standards to govern the human element of information security, once data leaves the network, it enters the wild west of application code and business logic. Many companies have traditionally relied on network-based solutions, like web application firewalls (WAFs), to provide protection beyond the network. But in order to protect vulnerable application code, security ultimately needs to be inside the application code itself.

This is where runtime security solutions can automate the safeguarding of applications without the need for human interaction. The purpose of runtime application self-protection (RASP) is to run alongside or better yet, inside the execution of application code.

By offering this ‘in-app’ protection, RASP is capable of defending against threats to the entire application stack: business logic, open-source libraries, third-party frameworks, and even the runtime platform itself. In addition to the added layer of defense for production applications, the close proximately of RASP solutions can also allow users to deploy virtual patches and remediate vulnerabilities that may have been inadvertently introduced during development.

Traditional application security, like the web application firewall, detects attacks by detecting exploits, but accurately blocking them is where it gets tricky since network firewalls can only operate upon network packets with signature-analysis and pattern matching for known payloads.  This leaves application code – the root cause of where the vulnerabilities live – untouched and unaddressed.  When only operating at the network layer, IT teams have to deal with the trade-off between the risk of blocking legitimate traffic or having to manage a flood of erroneous alerts, without actually solving the root cause of their security concerns.

While there may not be a Level 8 in the OSI model yet, security engineers can and should move proactively to protect their enterprise applications by moving protection inside the application code — after all, application code is the last and ultimate line of defense between a cybersecurity thread and a successful exploit.  Fix the code and you fix the vulnerability!

John Adams is the chief executive officer of Waratek. As CEO, John has complete responsibility for developing markets and operating all aspects of the organization’s global business. John has a rich history in security and medical technology with his experience spanning more than two decades. Prior to Waratek, John served as President & COO of SecurAmerica and Chairman & CEO of American Security Programs, leading the company’s expansion into nearly three-dozen new geographic markets and growing the company from 5 employees to over 5,000. In his career, John has also served as SVP N. America for London-based G4S (formerly Securicor) and held senior executive positions at US Surgical Corporation and Medline Industries. John holds an MBA in Healthcare Administration from Webster University and a BS in Business Administration/Accounting from Florida Southern College. 

The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.

SHARE

Subscribe Now to receive Free Newsletter

* indicates required


By submitting this form, you are consenting to receive marketing emails from: EC-Council, 101 C Sun Ave. NE, Albuquerque, NM, 87109, http://www.eccouncil.org. You can revoke your consent to receive emails at any time by using the SafeUnsubscribe® link, found at the bottom of every email. Emails are serviced by Constant Contact