The time is coming for a spring clean: has your IT architecture been collecting dust too?

Who doesn’t know about those annoying, slightly “mildewed” legacy issues that we have to deal with, not just in our private lives, but also in IT, where legacy issues, what are called “technical debts”, are a hindrance to business. So it’s high time for an IT spring clean to clear them out. In this blog post, we’ll show you where legacy issues might be lurking, and how to identify and eliminate them.

In software development, code that is not completely beyond reproach is referred to as “code smells”. These “smells” also exist in IT security architecture. These arise when best practice is not adequately followed due to constraints, inadequate knowledge or convenience, among other factors. In our “InfoGuard home pharmacy” we explain in a fun way the key components of an IT security architecture in terms of organs, disease patterns, pathogens, complications and potential treatments. The comments below follow this model.

If you identify one of the following symptoms in relation to your company, this could be a sign of having IT security architecture “smells”:

Long development cycles, a heavy workload and consequently, high rates of errors
Lack of documentation and knowledge about the components
Shadow IT, because it takes too long or does not work at all in the conventional way.
Analysis paralysis: projects do not get beyond the analysis phase

“Smells” develop gradually

There is a time lag involved in a smell developing. After all, food that has been stored incorrectly does not start to go bad on day one... Companies can neglect their IT security architecture maintenance for a while, and the effects are usually only visible or noticeable after a year or two.

If the IT security architecture is neglected, what is initially an invisible wave of bugs arises, known as the “back log”. Until the consequences become visible, there are often “sins” that are committed in several places at once. The result? The IT department loses the ability to assist the business with the operation and innovation of services in a prompt fashion. “Getting rid” of the smells is put on the back burner, until the wave of bugs hits with its undesirable effects mentioned above. That is why the company’s IT security architecture should not just be running along with the company, it requires active attention.

Tackling the problem at its IT root: causal investigation

The list of clinical symptoms depicted here is not an exhaustive one. The list shows key causes of “smells” in the IT security architecture.

Clinical symptoms	Pathogen / smell	Complications	Medication
Copy / Paste	Functionality is copied from application A to application B.	Functionality must be tested twice (in applications A and B).	Application A makes the functionality available to application B via an interface (API).
Time constraints	Due to lack of time, “technical debts” are built up.	The loss of ability to use technology that has become established as “commodities”.	Keep the technology stack up to date, so that standard, commercially available technology can be used.
Changing requirements	Unclear requirements lead to a lot of changes in scope.	Additional development and test cycles because of changing requirements; no clear acceptance criteria.	Define the requirements and the subsequent scope.
Missing / lack of documentation	Documentation will be issued later on.	Staff cannot learn efficiently; inability to create new functionalities.	Functionality, code and documentation are produced and made accessible simultaneously.
Absence of a target vision	For every project, only the components that are specifically required are created; stand-alone solutions.	Duplication of effort in the creation and synchronisation of components; no company-wide use of components.	Proceed according to plan with consultation with higher-level bodies, e.g. IT security architecture boards.
Internal conflict of interests	Differing views lead to different approaches to solutions that are incompatible.	Dissipation of staff energy and frustration.	Discuss the various opinions and reach a consensus in architectural committees.
Faith in technology and ignorance	Everything that is new is good and will solve all the problems, e.g. the Cloud.	The “technology zoo” and the difficulty of finding or training employees with the appropriate expertise; technology stacks that do not match the company’s needs.	Check whether the new solution concepts are a good fit for the existing IT security architecture.

Effects of technical debts: sluggishness...

Let’s take a real-life scenario that is likely to happen again in the future: a weak cryptographic algorithm will stop being used as a result of a security recommendation, and is to be replaced by a stronger one. The CEO thinks it is important to promptly notify the customers that this security gap has been successfully dealt with. A flurry of activity breaks out in the IT department – task forces are set up and escalations are started, and the following tasks are tackled:

Which applications and systems use the algorithm that is to be replaced?
Who can implement the security fix?
What is the intended use for the relevant systems and applications?
Which data flows are carried out using the relevant systems and applications?

Is this the task you have been assigned? Then your task is made up of the following sub-steps:

Your task	IT security architecture is in a… good state	IT security architecture is in a… poor state
Find components	Consult the company-wide architecture specification with the components used. Consult the CMDB.	Canvass, “reverse engineering”
Find the system & application owners	Consult the component owner list.	Ask around
Find the affected components	Interrogate the configuration management tools Analysis of the centrally used cryptography infrastructure Use of scanning tools, e.g. analysis TLS handshake	Analyse code Analyse code Ask around
Identify dependencies	Consult the company-wide architectural description with the components used. Consult the CMDB.	Ask around, scan
Replace the vulnerable algorithm	Change the configuration in the centrally used component for cryptography.	Correction in the components’ code; system update.
Test and deploy	Automatic Build, Smoke Test and Deployment	Manual testing and deployment
Prepare customer communication	Consultation of the component documentation (application A needs database X) and customer Y has these components in use.	Ask around

The compilation shows that, depending on the state of the IT security architecture in the company, the procedure and costs may vary: depending on their state, these tasks may involve a lot of time, energy and stress – or they may just be “standard tasks”. If the IT security architecture is in good shape, you can be confident that no essential components have been overlooked.

Prolonged recovery

As explained earlier, companies can neglect the maintenance of the IT security architecture for a while, but if you wait too long, the resulting problems can get out of hand and become difficult to tackle.

People often call for “everything to be in the cloud”, or for other radical solutions. If cloud migration can treat the “diseases” that have been identified, then IT as a whole can recover. If not, the patient is effectively just being transferred to another hospital.

Thinking it over helps

When it comes to questions about IT security architecture, as is so often the case, it’s worth just thinking things through. Decisions about architecture have a long-term effect, so they should be made with care and not taken hastily. It’s also a good idea to consult widely with the appropriate departments in the company. Doing so creates the right conditions for a sustainable architecture and a long-term benefit.

When can external support be helpful? Clearly, it is when there is insufficient internal knowledge and experience in IT security architecture, or when a decision needs to be scrutinised before it’s implemented.

InfoGuard is your expert partner for IT security architecture

InfoGuard has the knowledge and experience in various areas of IT security. Me and my colleagues travel far and wide not just working on IT security, we are also working on security architecture in the office. Numerous customers are already benefiting from this network of knowledge – maybe shortly, you will too.