Author
Markus Pfister
Published
22. February 2021
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 |
|
|
|
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.
Contact us! We will be happy to advise you and find the ideal customised solution to fit your needs.
