Today we are in the final weekend of 2020.  And as such, we here at AST Cybersecurity wish everybody a Happy New Year, and may all of your dreams come true, given all of the craziness that we have today.  My next blog to you will be coming on January 2nd, 2021. 

So as such as we are wrapping up today our blog series of what could potentially happen in the Cyber Threat Landscape.  So what is the last topic you may be wondering?

Well, it is has to something that I have actually written about before.  And that is the topic of source code security.  When you visit a website, such as an online store, or even your banking site, there probably is not too much thought given on your part as to how it was designed and created. 

All you want is to have the ability to login in safely and securely and do whatever you need to do.

But after COVID19 hit, many websites from any kind of industry were targeted.  Not only was the Cyberattacker able to replicate the site so that it looked real, but also, they were able to penetrate the legitimate website and deploy malicious code from there. 

True, this has always been a threat variant, but this topic has started to take front and center stage today and will even be more so going into 2021.

Why is the case you may be asking?  Well, the bottom line is that software development teams, no matter where they may be located in the world, are always under great pressure to deliver the final project to the client on time, and in the best-case scenario, also under budget. 

Because of this, security has always been a last concern, and even if it was done, it was a last-minute chore done haphazardly. 

Now that many software development tools are automated (driven primarily by AI and ML), the thought of not testing the source code from the standpoint of security still persist.  But even more so, many development teams are making use of what are known as “Open Source” API libraries, which bridges the backend to the front end of the web-based application, and vice versa. 

Very often also, these APIs have not been tested, and many software developers think that since they were downloaded from a reputable source (such as GitHub), they should be safe to use.  But once again, this is far from what reality dictates.

Given this newfound world of automation that is transpiring, there is yet another new concept that is coming in the software development world.  This is known technically as the “Infrastructure as a Code” (aka “IaC”), which basically takes out the human factor even more. 

But it is important to keep in mind that IaC (as far as I know) is only used so far in those conditions and environments in which the same source code is used over and over again, with some modifications being made.  In other words, at the present time, this concept cannot be used when brand new source code has to be written and compiled from scratch. 

But even here too, the software development team needs to take security seriously, as any backdoor can lead to a point of entry for the Cyberattacker which will then allow them to deploy their malicious payloads, and a result, cause all kinds of havoc, which can happen very quickly and basically bring a business to its knees in just a matter of a few minutes.

So, if you are a Project Manager or even a CISO that is leading the chare of a software development team, here are some recommended security precautions that you should seriously take into consideration as a result:

*Keep stock of the first iteration:

Creating source code for whatever application often means that there will be a first cut of it. From here, newer and more enhanced modules will then be added onto it, with of course many changes and iterations taking place in between.  Therefore, it is always very important to keep a first version of this stored somewhere that is safe and secure, and that only a very limited amount of people have actual access to it.  In fact, you should apply Two Factor Authentication (2FA) in order to truly confirm the identity of the individual that is trying to access the source code.  The reason for doing this is that you do not want the Cyberattacker to get access to this first cut.  The only way they can figure this out is by literally working backwards from the source code that they may already have hacked into.  Plus, if for some drastic reason or another you need to start the project all over again, you will have the baseline code already at hand.

*Maintain access control:

This goes back to the last bullet.  You only want to give access to the source code for those individuals that absolutely need to access it so that the web application can still continue to be developed.  Once again, you should use even something more powerful than that of 2FA, and this is known as “Multifactor Authentication”, or “MFA” for short.  This is where you deploy at least three or more layers of authentication mechanisms in place to confirm the legitimacy of the individual.  Now, if the project is big enough where you have to have a team of perhaps more than five software developers on hand, a good rule of thumb here is to give access to only those modules that are being worked on.  For example, you could probably break down your software development team into different subgroups, and only one subgroup will thus only have access to that particular module that they are working on, and nothing else, unless they have the written authorization to do so. 

*Auditing and Compliance:

When we hear of these two terms, the thoughts of the GDPR and the CCPA often come about.  While it is true that the source code has to be compliant with these two legislative mandates from the standpoint of data privacy, the source code also needs to be QA checked on a random basis to make sure that all is good.  This simply means that any new changes or iterations that have been introduced needs to be double checked to make sure that all of the other modules are working in synch together.  Thus in this regard, you always want to maintain a version history of the source code from the inception to the very end, and a good versioning tool will let you do this.  There are a lot of free ones out there, so take a peek around to see what works best for your environment.  Also, another thing you can implement here is to have regular change management review meetings as the web application is being developed.  This will serve as a system of checks and balances for all parties that are involved in the project.

*Define the path to production:

There is no doubt that the creation and development of a web-based application can be a massive undertaking, with a lot of people involved.  Therefore, communications will be key here, for both internal and external stakeholders.  In other words, everybody involved in the project needs to be fully aware of and comprehend the “Path to Production”, which involves the very inception of the project to its final delivery to the client, with all of the major milestones mapped out and discussed on a regular basis. Remember, security also means communicating what flaws have been discovered and how they were specifically mitigated.  After all, two or more heads is better than one when it comes to creating new ideas in this regard/

My Thoughts On This:

I am by no means a software developer and have no intentions of doing it.  But I sure do understand Cybersecurity well enough and know that the source code must be tested before you hand it off to the client.  Therefore, rather than waiting until the last minute to do this, testing for any vulnerabilities, weaknesses, or gaps should be done on a modular level.

This simply means that as each source code module is done, it should be thoroughly tested before moving onto the next development module.  This will help to avoid any kind type or kind of cascading effect onto the other modules should any glitches be found in the previous ones. 

However, if the web application project is small enough, you may even want to consider using a concept which is known as the “Guardrails”.  In this instance, the development subsequent source code modules does not have to necessarily stop until the previous ones have been approved. 

The source code can still move through, as long as there are strict permutations that are put into place and closely followed.

The bottom line here to remember is that ultimately your organization is responsible for the Cybersecurity of the source code that you are developing for the client.  If there any hacks or security breaches that occur after the fact, you will be held liable, and also from a financial standpoint!!!