drwxr

“Underlining” problems of software implementation

Today, when considering security aspects, there are many different techniques to implement software and systems, most of them focus on implementation and test/verification. Majority of research in this area is related to develop new tools to check the integrity of the software later, during the verification phase.

To understand design phases that this post considers as baseline, considers the following systems life cycle phases:

This post introduces a life cycle phase that can be called as conceptual phase. The conceptual phase sometimes is “neglected” due to misunderstood and normally including excuses related to restrictions such as cost, time, and limited resources (summarized as “wasting time” with a conceptual phase).

In IT business, this consideration of time is more crucial because technology evolution has a high pace and launching solutions to market is crucial to survive and guarantee a market share and right time to market.

To support this conceptual phase, we presents a tool called “IDEF0” to give an example and illustrated the importance of knowing everything that interacts with your system or function. The objective is to provide an early knowledge about your System of Interest anticipating events, states and conditions that will emerges during implementation phase or even worst, during operation phase (after deploy, during users usage).

First step is to understand that the system that you will implement has interfaces to others (e.g. users, systems, environment, etc.) requiring inputs, processing these inputs (function/system objective) and providing outputs which are subjected, during “processing”, to controls and mechanism entities (e.g. power, statuses, etc.) so your system is no more a lonely entity and you anticipate stakeholders that interacts to your system and what is normally expected from them.

Now, your system has a set of interfaces that you need to understand and so, create a set of requirements that met these interfaces (what it shall accomplish). At this point, when you need to understand the users or other systems’ needs, we bring a concept that help you develop better systems, this concept is called, Systems Thinking.

Systems thinking is a capability of developer to view all entities that comprise the system or where it is part of (holistic approach), with System being a set of parts that relate to each other. The most important element in a system view – and sometimes neglected – is the relations among these entities.

With the tool presented and in this conceptual phase it is essential to have an abstraction level of your architecture to understand and identify all the relations of your System of Interest, which is your system under analysis. This abstraction level requires an approach that avoids the implementation decisions (e.g., it will run a specific Operating System) and thinking just about functions and exchanges between entities and stakeholders (e.g. data, energy).

The interface map and correlation of functions empowers developers with the capability to create scenarios that the system will operate and understand the possible threats that can emerge from these scenarios (e.g. if system lose specific input).

After this initial analysis, you have a list of your system functions (it shall comply), you have a map of your systems interfaces and you have concepts of operation (or scenarios) for your system (e.g. normal operation, power interruption). With these information, and considering the security aspects you are able to conduct a preliminary security assessment; anticipating cases or flaws prior to implementation or deploy, reducing future fixes (costly).

During the conceptual phase analysis, you design the system in a high abstraction level allowing early analysis and deriving requirements and constraints that your system requires (e.g. input values – string with X characters – avoiding buffer overflows).

After, it is possible to proceed to the next phase, implementation, where the “code” is developed considering these requirements and constraints raised during conceptual phase that complements the initial objectives. This approach can also be called as Requirements Driven, although this term is very common during software development environment, in general, it is not regarding the entire lifecycle or as proposed during a conceptual analysis in a higher abstraction layer.

An interesting case about architectural security is related to Redis (read more at http://antirez.com/news/96)

Conclusion,

There are problems related to security that cannot be classified as an implementation issue (e.g. flaws) but a bad requirement specification or lack of it, like environment and operational considerations/analysis. Therefore, it could be anticipated with a conceptual phase analysis, which would lead to the development of a more resilient architecture.

This is a simple view of the importance that must be given to a conceptual phase and consequently requirements definitions when developing a system or implementing a code. I hope that this post may be useful to open your mind and if you have, some questions contact us to clarify the concepts and the perspective about this subject.