SolarWinds is a well-known company that provides the tools & offers services for real-time monitoring and analyzing the IT infrastructure & Applications, it’s “easy-to-use” interface makes it popular amongst many large-scale corporations, mid-market & small businesses across the globe.

In 2020, a major cyberattack (popularly known as “SolarWinds Supply chain attack”) suspected to have been committed by a group known as “cozy bear” backed by the Russian government penetrated thousands (estimated to be 18,000+) of organizations globally including the likes of Microsoft, Google, Intel to name a few. Even multiple departments of the United States federal government were not spared, Intelligence agencies also suspect that this attack could have stolen critical insights on covid-19 vaccine research.

Ironically the hackers first gained access to the SolarWinds systems in January 2019 and the attack not being publicly discovered or reported until December 2020, several months earlier than previously known , revealed Mr. Sudhakar Ramakrishna CEO @SolarWinds.

Just like programmers across the globe, even SolarWinds Orion programmers leveraged GitHub for distributed version control and source code management which mostly has sensitive information which unfortunately got compromised because someone mistakenly marked it public instead of private. According to the company sources one of their Interns (who is no more working) probably used a fairly simple password “solarwinds123 whichever the case maybe it opened the door for the hackers who could have then meddled with and usernames and passwords & even deployed malicious software update package called sunburst into the build process this then allowed them to target SolarWinds customers.

However, this intrusion was first uncovered by the cyber security company FireEye because it too was a victim of this attack & it was detected when one of the employees of FireEye got a request to reset their multi-factor authentication which they had not done.

Here is the list of practices Companies could adapt in order to prevent SolarWinds & similar kinds of attacks :

• By deploying a proven Two-factor authentication along with a third-party password manager
• By keeping their Security & Network Appliances (AV, Firewalls, Switches, Routers, etc. ) & Software (Applications, Databases, Operating Systems, etc.) patches updated
• By training their employees using interactive training methods comprising of videos, simulations, quizzes, etc.
• By making Network VA/PT & Application code reviews a regular practice

Log4j is a popular open-source logging library written in Java. It helps to organize and manage the flow of logs from applications ,filter them and send them to different output streams. Log4j solves the problem of having to choose between too many types of logging methods to use. It was designed for scalability and so it can log a large amount of information without slowing down or crashing an application. That’s why it is so popular – developers use it because it’s easy to set up and configure, yet offers advanced features for specialized requirements.

In December 2018, a new vulnerability in the open-source logging library Log4J was revealed by an independent security researcher. He discovered that a vulnerability in the way the library handles exceptions allows an attacker to compromise any log file with a crafted exception message. The researcher even tested this vulnerability on various applications and found that it affects more than 500 million endpoints & the list includes over 7,000 corporate networks and 4.7 million servers of even some of the large companies such as Amazon, Tesla, Uber, Netflix, Spotify and Microsoft. The risk of exploitation is high and the exploit is publicly available as well as being very easy to execute.

The Log4j Java library has a vulnerability that could allow attackers to take over systems running OS including Linux, OS X, and Windows. It’s ability to easily bypass even the firewalls and subvert any system makes it vulnerable to external attacks And it can be exploited by anyone who can access the machine via a local network or remotely through a VPN connection . It’s mostly used by hackers in attacks that allows hackers to install crypto currency mining software on systems. Recently an Iranian group of hackers has also tried to use this vulnerability to breach some government agencies of Israel according checkpoint cyber security company.

Vulnerabilities in Log4j allow denial-of-service attacks to be executed remotely, which can extract data from the logs. The following are the main consequences of this vulnerability:

• An attacker can send arbitrary requests to the API, which allows them to execute arbitrary code on the system
• A user may be tricked into opening a malicious file and executing any code included in it
• An attacker may be able to use this vulnerability to cause denial of service among other things
• Vulnerability may allow an unauthenticated remote attacker who sends specially crafted requests to force an application

The vulnerability has been confirmed in “Log4j 1.2.17” and “Log4j 1.2.6”  & the bug was first identified on November 16th, 2017 by the researcher who goes by the online alias “gclayc.” . Thankfully the vulnerability has been fixed in “Log4j 2.8”, which is released on December 19th 2017 and is available from the Maven Central Repository . Security researcher, Denis Kutovoy from the Russian company Digital Security has recently published proof of concept for this vulnerability on GitHub.

The only protection against it is to update your Log4J installation to the latest version as soon as possible .If you are still not sure if your machine is vulnerable, you can test it by running “java -jar ds_log4j_vuln_poc1.0-SNAPSHOT-all

Cloud repatriation become more popular in recent years. Trend shows that many businesses that have adopted cloud first strategies have seen rise in cost, performance drop, compliance issues and are now started migrating the data from public cloud environment. Companies are now taking a more conservative approach to cloud adoption, repatriating some workloads to other available infrastructures. As part of ongoing infrastructure modernization and optimization efforts, these repatriated workloads are now being deployed across multiple platforms and various models.

Why this Cloud Repatriation

What drives companies to engage in cloud repatriation? It turns out that failing to specify the business goal of a cloud migration, along with poor migration planning ultimately results in disappointments. Furthermore, the reality of a cloud deployment can be so different from what a business executive or an IT leader were expected. This ultimately results in cloud repatriation. The real issue can be pointed as the enterprises are assuming cloud works just like their corporate data centre and the cloud service providers are claiming their cloud services are easy and less expensive. The cloud repatriation phenomenon we see today is due to these fundamental misunderstandings.

No proper planning

A lot of organizations are migrating their systems to the cloud. However, not all of them are doing it in a planned way. This can lead to numerous problems for the company. Cloud migration is a complex process that requires careful planning and implementation and lacking of them leads to failure.  Many companies rushed to the cloud without conducting the essential assessments and planning. Without a roadmap or planning, the cloud can be complex, expensive and less secure. Poor initial road mapping and failed migrations are ultimately resulting in cloud repatriation.

Cost Factor – which is not always the way companies think

IT leaders must reconcile the migration with incoming analyses and reports once they’ve moved to the cloud. Unfortunately, errors in the evaluation and relocation planning have resulted in less than expected results. Cost is one of the possible factors in cloud migration.

Though In practise, cloud expenses for a task can include numbers of related and required resources. This can include expenses for server instances, storages, related required paid services, and other costs that aren’t visible when deploying a workload to the public cloud. And hence, the complex cloud workloads may cost more than expected.

Companies may have overestimated the cost savings from the cloud and when concluded companies repatriate in order to get the required objectives.

Security and vulnerability

The public cloud is not intrinsically less secure than a private data centre from technology perspective. When data leaks or improper access occurs, the cause is frequently attributed to the cloud user’s lack of setting and precaution. In many cases it was found that many companies understand this too late. Given the nature of remote access, granular access control within the public cloud, and the added security expectations of modern corporate and regulatory compliance, some important tasks may not be suitable for the cloud. Emerging news about several data breaches on cloud servers make the IT leaders to rethink about the cloud migration, or they may believe that a more diversified cloud storage approach better suits their needs. All these things make the companies shift back to on-premise infrastructure.

GBB comes with an experience of optimizing workloads across Public cloud environments or even setting up a Hybrid cloud infrastructure for hundreds of customers across multiple industry verticals such as Pharma , Manufacturing , Healthcare customers , Universities & Government (State & Central) Departments .

Give us a shout at 91 810627 7143