With the advent of the Remote Workforce today and everything pretty much going now mobile and virtual, businesses across Corporate American are now trying to figure out new methods in which both employees and customers can access needed resources in a quick and timely fashion.
Of course, this all comes down to the nuts and bolts of the Web based applications that are being built. Now, I am far from being a Web developer, but there has been one issue in this regard that has been overlooked quite a bit.
And that is, the security that goes into building the actual Web app. In this regard, I am talking in particular about the source code that is being used to create them. Many software developers are cognizant of this problem, but the real issue is that they often wait until the very last minute to test the source code, if they do anything at all.
Many times, this is a forgotten about issue and then the real problem occurs when the hand off to the client actually occurs, and then a security breach occurs.
But also keep in mind that many Web apps of today are not coded straight from scratch. Many of them make use of source code that has been compiled before, but further tweaked around so that it can fit the needs of the project at hand. Very often APIs are used as well. But also, Content Management Systems (CMSs) that are also widely used to create them.
One such platform is known as “Word Press”. It is a very popular suite of tools to use, and in fact well over 33% of all businesses use Word Press as the main vehicle for creating their Web app.
But it too is prone to security vulnerabilities as well, and often requires updates. Now, to be honest, I know nothing of Word Press, other than just how to post a blog, just like this one. But I am aware of some of the security issues that are involved with it, and in today’s post, we are going to review some proactive steps that you can take to help protect the web app you build using Word Press:
*Picture the Web app in the Cyber Threat Landscape:
When we talk about this in the world of Cybersecurity, normally we think of it after the fact. For example, once the Web app has been formally launched and deployed, only then does the IT Security team put it into the Threat Landscape models in order to predict the attack vectors that could impact it. But why not take one step forwards, and think about how your proposed Web app will fit into the Cyber Threat Landscape even before you start to create it??? Now of course, this will be just a preliminary analysis and things will obviously change as you create it, but by taking a step back first and asking some serious questions about it, the proactive mindset that is needed to test the source code on a modular basis will also start to take root. Some typical questions that you can ask in this regard is what kinds of confidential information and data will be stored and processed on it, who will be accessing it, what are some of the potential weak spots, etc.? Asking and answering these kinds of questions before hand will not only give you an insight into the potential security risks that you could potentially face, but even will refine the scope of the project into more realistic terms when to comes to final deliver. Remember, you don’t have to go at this alone, you can also make use of AI and ML tools as well to help you predict how your Web app will fit into this unique landscape well ahead of time.
*Always keep it updated:
Just like anything else, you also need to make sure that your Word Press (WP) based app is kept up to date with the latest software patches and upgrades. Now, I am not at all familiar with this process, I usually leave it up to my Web team to do it. But I so know the process is different than say, applying upgrades to Windows 10. Do if you are a novice to WP, I would recommend that you get someone who knows a lot more about this to help you out initially. Also, the same is true of passwords. Always keep changing it from both the backend and the frontend, on a regular basis, and always when employees leave for whatever reason. Even consider making use of Multi Factor Authentication (MFA) and One Time Passwords (OTPs).
*Make sure that the Plug Ins are updated:
Word Press makes use of a certain feature called “Plug Ins” in order to help you create your Web app. Once again, I am not at all familiar with any of this, but one thing I do know is that they are prone to some serious Cyber Threats out there, such as Cross Site Scripting (XSS), Remote Code Execution (RCE), SQL Injection Attacks, Cross Site Request Forgery (CSRF), etc. Many of these Plug Ins are also written in the PHP scripting language, which make the more vulnerable. In fact, these three threat variants just mentioned are already listed in the OWASP Top Ten for Web app security risks.
*Review the NIST documentation:
One of the other big buzzwords to come out today is that of “NIST”. This is an acronym that merely stands for the “National Institute of Standards and Technology”. This is the organization that comes out with all of the Frameworks that helps businesses in Corporate America come into compliance with the mandates of the CCPA, GDPR, HIPAA, etc., and other such regulatory pieces of legislation. There are different types of “Frameworks” out there for these very purposes, and in fact there is one set of NIST documentation that deals specifically with Web app security. This is known as the “NIST SP 800-53”, and it can be downloaded from this link:
In this regard, there are two solutions that can be used, and they are as follows:
*The Runtime Application Self-Protection (RASP):
This is a suggested set of tools and technologies that can actually be deployed physically upon the same server in which the Web app resides upon, thus offering it even greater protection in a real time, and on a continual basis. This is far different than “Perimeter Security”, which are the security tools and technologies that sit at the perimeter of the defense lines at the company, which separates it from the external and internal environments.
*The Interactive Application Security Testing (IAST):
This is a series of guidelines and procedures that the software development should follow when testing the security of the source code, and its further stresses that it should be done at the modular level, rather than waiting until the very end to test. Further, it also highly recommends that the company that is developing the Web app to also Cyber test the source code from both the internal and external environments, by making use of both Penetration Testing and Threat Hunting exercises. These activities should even be done after the Web app has been delivered, at least on a quarterly basis, if not more. This process can also be referred to as “Design, Scan, Check”.
My Thoughts On This:
Because Word Press is so widely used (as previously stated), the fallacy in thinking is that it must be already safe to use. But this is far from the truth. For example, at the heard of Word Press are its Plug Ins, and this is where most of the security breaches precipitate at: So far, well over 1.5 million Word Press sites have impacted by Cyber Threat Variants, and these can be traced back to more than 50,000 Plug Ins that the platform uses (wow, didn’t know before it had so many of them).
So, make sure you keep those Plug Ins updated at all times, and try to use the ones that are deemed to be amongst the most secure. I believe that many of these Plug Ins are free to use but keep this mantra in mind: You get what you pay for. In other words, it might be wise in the end to spend some extra $$$$ in getting those Plug Ins that have great security features already built into them.