Blog Post Series about Software Security

We’ll cover essential software security topics in a new series of blog posts to increase awareness about cyber security in the field of software information security. elfGROUP has worked with software and application security testing for almost a decade. With this experience we can state that nearly all information security vulnerabilities found in applications have been result of insufficient information security activities in planning or development stages of software production. In those cases, information security has not been built systematically and by default as part of the system’s core. That is why we want to increase the visibility and conversation to integrate information security with software development processes and to get managing information security as a pivotal part of each stage of software development.

In this first part of the blog series I explore security related characteristics of typical multilayered architectures found in web-based information systems and the role of software security in executing a successful information security model.

 

Taking the Architectural Elevator to the Penthouse – Information System Tiers in Software Development

There are about as many software architecture tier models as there are articles written about the subject or information systems build around it. Terminology in the field isn’t really established, and the subject can be addressed in the extent of a complete information system architecture or a single software architecture. For information security, what matters is the entity, because one weak link is enough to endanger the security of information or give the intruder a foothold for a wider invasion. The structure of an information system is typically seen as a logical and structured multilayered architecture, where each layer of the architecture has their own responsibilities and a functional role in producing the whole system. Understanding multilayered architecture and focusing information security requirements and controls to the architecture layers is crucial from the point of view of ensuring the information security of the information system, so that information security mechanisms became effective and the information system becomes secure.

A typical web-based information system has several layers:

  • the end user layer (end-users of the service, also potential intruders)
  • frontend i.e. user interface layer (Javascript, React, HTML)
  • frontend runtime environment i.e. the browser (Firefox, Chrome, IE)
  • connectivity layer (Internet) (IP, TCP, HTTP, TLS)
  • service provider network infrastructure and network protection (operators, firewalls, IDS/IPS)
  • load balancers (BIG-IP, Nginx, NetScaler)
  • web server layer (Apache, Nginx, IIS)
  • application server layer (WildFly, GlassFish, WebSphere, Pyramid, ASP.NET)
  • application layer (Java / Python / C++)
  • integration layer (message queues, file transfers, base integrations)
  • data storage layer (Oracle, MariaDB, MongoDB)

The layer model can be visualized and seen as a concrete route how the user’s intention (requested transaction) moves towards the information system’s bottom most layers’ business logic and data storage and possible integrated backend systems.

Someone could argue that the end user or the end user layer isn’t part of the information system architecture – and while technically it’s not part of the configuration – in building information security it is absolutely essential because it is the actions from this layer that can destabilize the whole construction, and in many cases enables  the data leakage possibilities that are the easiest to exploit. Penthouse can be windy at times, but while we wait for the AI era, we’ll have to concentrate on reinforcing the lower layers.

In the case of web application, we can picture that user’s requests move in the architecture downwards, and the returned data or acknowledgement of task execution moves upwards. Dumb intermediate layers (that merely pass unchanged content onward) should be avoided, but unfortunately this rarely happens. The earlier corrupted or malformed payloads can be stopped in the elevator, the lesser resources are used to handle the problem, and the safer are the critical elements of the platform. It should be noted that the direction of the elevator and the current layer doesn’t matter here.

Role of software security

No Need for Helmet, If You Don’t Intend to Fall? – Protection Methods Through Secure Multilayer Architecture

No matter what system or platform in question, information security should be built for the depth of the whole architecture stack, with the so-called security-in-depth principle, i.e. following the onion model. Each layer and each component along the way has to resist potential intruders, malformed inputs, requests without proper authorization or attempted privilege escalations, unknown resource references, processing causing infinite loops, unhandled exceptions, unexpected return values, events conflicting with session state etc. The list could go on forever.

If protective measures from one layer would be to fail, and the implementation would be unsuccessful to recognize such an erroneous state, the next layer could patch up the situation on its turn processing the request. When the principle of the onion model is baked in into software requirements management and considered in project resourcing, it becomes the default operating model that is taken into account also during functional testing. All the exceptions and errors cannot be foreseen beforehand. Thus, the best protective measure is to prepare thoroughly on as many different levels as possible.

 

Software Security Even with Eyes Stinging – Supporting Secure Software Development by Systematic Security Work

Software security is present in all the technical layers of an architectural stack. From the point of view of a web application producer, most of the stack consists of software developed by someone else, when the implementations use more and more complex frameworks and libraries, not to mention distributed and cloud-based systems. In this case, it’s even more important to understand the outlines of responsibilities and the trust boundaries between components, maintain strict control in specifying information security requirements in all the phases of the development, and to oversee how they were fulfilled. As systems are increasingly complex and widespread, information security work and testing are compelled to be carried out in systematic, centralized and if possible, automated way. The architectural layers as well as software components and the data they process should be categorized according to the data content to be protected and events to be enabled. Not all layers can always be trusted, but their risks should be recognized and addressed, at minimum.

Criticality of data management and classification, as well as the correct implementation as part of the information security architecture, works strictly according to the platform’s trust boundaries. The information security of software and information systems should be seen as a broad subject, including both preventing malicious hacking, and ensuring the systems are working correctly and indisputably. There are several information security frameworks and models, that when applied systematically to business and software development, corporate cyber security can be improved substantially.

Software industry is still young and constantly takes huge leaps forward as the technology develops rapidly. The fundamentals have to be put in order, before the constantly developing technology is capitalized.


In the next parts of this blog series, we’ll examine aforementioned subjects, trust between different layers, classification of data, and building and assessing secure software architectures. One subject that fascinates me is understanding, improving and demonstrating information security using formal methods. That will also be discussed in future blog posts.