As widely anticipated, the conflict between Russia and Ukraine has heated up on cyberspace in the days since Vladimir Putin ordered his troops and tanks to invade.
This weekend saw the Kremlin’s official website at kremlin.ru brought down, along with other Russian government sites, in what appears to have been a co-ordinated distributed denial-of-service (DDoS) attack.
Read more in my article on the Hot for Security blog.
A game, developed by the so-called IT Army of Ukraine, makes it easy for anyone around the world to contribute to the overloading of Russian websites while playing a version of the simple sliding puzzle “2048.”
Tarah Wheeler and Josephine Wolff analyze a recent court decision that the NotPetya attacks are not considered an act of war under the wording of Merck’s insurance policy, and that the insurers must pay the $1B+ claim. Wheeler and Wolff argue that the judge “did the right thing for the wrong reasons..”
Wiper malware has been detected abusing legitimate drivers and targeting Active Directory servers amid ongoing Russian military conflict in Ukraine. The campaign reflects a growing trend of malware use during geopolitical crises with organizations urged to mitigate risks.
Discovered by ESET researchers on February 23, the malware, named HermeticWiper, has been installed on hundreds of machines in the country and indicates that there is no longer a distinction between cybersecurity and international security during crises. This follows recent DDoS attacks against several Ukrainian websites, the deployment of an EU cyber rapid-response team committed to helping defend Ukraine from cyberattacks, and warnings of potential ransomware attacks against US organizations in the wake of new sanctions placed on Russian banks and elites by President Biden.
In the first article in this series we covered the basics. In the second article about the planning process, we covered how developers incorporate security at the beginning of their project. This article explores DevSecOps during the Continuous Integration (CI) phase of the coding process and how to protect the code from supply chain attacks, license issues, and theft. Developers are advised during planning to use secure coding best-practices during the coding process.
The focus of DevSecOps in the coding process switches to securing the source code developers write. Code is stored in a centralized repository where it is now the single source of truth. From the repository, code can be retrieved and modified by other developers and automation tools.
A source code repository “repo” is a centralized file storage location that uses a revision control system to retain the history of file changes and comments from the developers on why changes were made. Repos also allow collaboration within a team of developers who are working on the same project while being protected from overlapping or conflicting changes. Developers have a choice of which repo to use based on requirements and purpose of the software they’re building. For example, a public repo would be appropriate for open source (FOSS) while a private repo may be needed to protect the proprietary software code “crown jewels” of the business.
Software as a Service “SaaS” repo websites like Github, Gitlab, and Bitbucket are examples of public repos where people can store a project, collaborate, and share with others around the world. Because public repos are accessible from the Internet, they are designed primarily to be available to everyone.
Private repos in services like Azure DevOps (can be public or private) or an on-premises setup of Gitlab offer additional layers of security but also come with more administrative overhead. Network security controls like virtual private network (VPN) access, firewalls, data loss protection (DLP) systems, and intrusion detection / protection systems protect the private repo from malicious activity. The overhead of managing and administering the private repo platform falls on the company.
In addition to administering system level security, the company must also maintain patches, version upgrades, and availability to protect the repo. The benefit is increased security and privacy because the repo should be accessible only to those within the company. The following sections are additional layers of security to consider when implementing for all repos.
Authentication verifies who the requester is and authorization defines what the requester has access to. Access to the repo for a project should operate with the principal of least privilege. In other words, only the developers and tools that need access to the repo are authorized. In most cases, the project owner will approve or deny all user access requests to the repo. The owner can also grant the necessary permissions based on the type of user.
For example, an auditor may only need read-only access while a developer would need to add or modify items in the repository. For private repos, DevSecOps recommends authentication be integrated into the company’s single sign-on (SSO) platform and multifactor authentication (MFA) will provide a stronger measure of protection against password attacks.
A project in the repo most likely has several user stories that multiple developers are working on to deliver the application. The “main” branch of source code in the repo represents the “single source of truth”.
When a developer creates a feature branch, they are taking a snapshot of the code in the main branch and creating a copy to work on with their user story. When the developer completes the coding for the user story, they can merge their feature branch into the main branch.
Main branches aren’t always the best version of the software to send into production. Release branches are a snapshot of the main branch and dedicated to delivering a specific version of the application to production. Release branches offer additional control and can help with applying hot fixes for bugs or adding temporary features that may not need to be in the main branch.
Hot fixes are used to quickly solve a problem identified in production. They can also use a branching strategy to give developers time and flexibility while still quickly solving the problem. Hot fix branches make it easy to deliver a targeted resolution to a specific issue or vulnerability. For a temporary hot fix, the hot fix branch does not have to be merged into the next release. This often happens when a more long-term solution is being developed.
Merging from a feature branch into the main branch should be restricted from happening without a pull request. A pull request is a tool in repos that announces a desire by the developer for others on the team to review the changes they made. Other developers review the changes made and can send feedback for additional changes or approve the request to merge the code into the main branch. Once the peer review is complete, the pull request is approved, and the feature branch code is merged into the main branch to create a new “single source of truth”. After the merge is complete, the feature branch can be deleted.
There may be times when a developer wants to take the source code of an application and use it for an entirely different project than its original intention. In this case, the developer can create a new repo by forking (making a copy) the main branch from the current repo for the new project.
This is acceptable in the FOSS community because it fosters innovation and allows faster delivery of projects by reusing snippets of code. It also carries risks that malicious actors can create supply chain attacks through forking. Also, forking does not free the developer from the original license. For private repos, DevSecOps recommends that forking is disabled to prevent software code theft.
Not all applications have the same security requirements, which is based on the risk associated with the application source code. An application that is critical to revenue generation in the business may need more security than an informational website. The critical application may need to be hosted in a separate project or an entire source code repo platform can be created with separate authentication and authorization. The DevOps and DevSecOps models can support multiple repos and projects for however the business needs to adjust.
The decision for which software repository platform to use depends on several criteria including public or private, automated workflows, and seamless transitions that help the developer with their user story. Automation and easy to use security tools also promote DevSecOps and improve the security quality of code. Combined with continuous security training for developers, using the repo security features will protect companies from supply chain attacks, licensing issues, and code theft. The next step is to compile the code into a package or artifact using the build process.
Social media giant restricts access to state media and disrupts disinfo networks
The invasion of Ukraine by Russia is reason enough for all CISOs to place their teams at a heightened state of alert and readiness in the event of deleterious cyber actions by nation-state actors or the cybercriminal groups. Three areas that should be reviewed immediately are preparation for cyberattacks, supply chain disruption, and business continuity concerns.
NBC News reported on February 24, that the White House had been provided a plethora of cyber options which could be used against Russia, which included disrupting the internet, attacking infrastructure and transportation networks, which was sourced to “two U.S. intelligence officials, one Western intelligence official, and another person briefed on the matter.”
CERT-UA, the national Computer Emergency Response Team for Ukraine, has issued a warning of a major phishing campaign launched against military personnel.
The attack is being blamed on the UNC1151 hacking group , which is based in Minsk and whose members are said to be officers of the Ministry of Defence in Belarus.
Read more in my article on the Hot for Security blog.
