As fears mount over the prospects of a “cyberwar” initiated by the Russian government, the number of identified Russian threat actors also continues to climb. Last week CrowdStrike publicly revealed a Russia-nexus state-sponsored actor that it tracks as Ember Bear.

CrowdStrike says that Ember Bear (also known as UAC-0056, Lorec53, Lorec Bear, Bleeding Bear, Saint Bear) is likely an intelligence-gathering adversary group that has operated against government and military organizations in eastern Europe since early 2021. The group seems “motivated to weaponize the access and data obtained during their intrusions to support information operations (IO) aimed at creating public mistrust in targeted institutions and degrading government ability to counter Russian cyber operations,” according to CrowdStrike intelligence.

To read this article in full, please click here

Read More

In the previous article about the coding process, we covered developers using secure coding practices and how to secure the central code repository that represents the single source of truth. After coding is complete, developers move to the build and test processes of the Continuous Integration (CI) phase. These processes use automation to compile code and test it for errors, vulnerabilities, license conformity, unexpected behavior, and of course bugs in the application.

The focus of DevSecOps is to help developers follow secure-coding best practices and open-source licensing policy that were identified in the planning process. In addition, DevSecOps helps testers by providing automated scanning and testing capabilities within the build pipeline.

What is in a build pipeline?

Build pipelines run on highly customizable platforms like Microsoft Azure DevOps, Jenkins, and Gitlab. The build pipeline pulls source code from a repository and packages the software into an artifact. The artifact is then stored in a different repository (called a registry) where it can be retrieved by the release pipeline. Jobs in the build pipeline perform the step-by-step tasks to create an application build. The jobs can be grouped into stages and run sequentially every time the build process is run. Jobs need a build server, or pools of build servers to run the pipeline and return a built application for testing.

DevSecOps partners with developers by inserting additional source code scanning tools as jobs into the build pipeline. The tools used depend on what is being built and is usually determined through DevSecOps collaboration with the development team to understand the architecture and design of the code. For most projects, DevSecOps should implement at a minimum, the scanning tools that look for vulnerabilities, poor coding practices and license violations.

Source code scanners

Pipelines allow automated application security (AppSec) scans to be run every time a new build is created. This capability allows DevSecOps to integrate static analysis (lint) tools like source code scanners that can run early in the software development lifecycle. Security scanners come in two forms: static application security testing (SAST) and dynamic application security testing (DAST).

SAST is run early in the development lifecycle because it scans source code before it is compiled. DAST runs after the development cycle and is focused on finding the same types of vulnerabilities hackers look for while the application is running.

SAST can look for supply chain attacks, source code errors, vulnerabilities, poor coding practices, and free open-source software (FOSS) license violations. SAST speeds up code reviews and delivers valuable information early in the project so developers can incorporate better secure coding practices. Picking the right SAST tool is important because different tools can scan different coding languages. By automating scanning and providing feedback early in the development process, developers are empowered by DevSecOps to be proactive in making security related code changes before the code becomes an application.

Container image scanners

Application builds that create containers for microservices like Docker are stored in a registry as an image artifact. These images have application code, additional software packages, and dependencies that are needed to run the application. Sometimes the images are built by the developers and other times are pulled from a public repository like Github.

Source code scanners review the source code, image scanners review the built application, packages, and dependencies. Image scanners look for container vulnerabilities and exploits like supply chain attacks and crypto jacking software.

Image scanners should be run during the build process so that vulnerabilities are identified and remediated by the development team quickly. Keeping an image small (fewest needed packages and dependencies) is a great (and easy) way for developers to reduce the attack surface of the image and speed up security scanning and remediating vulnerabilities.

In addition to image scanning, DevSecOps recommends the following criteria to protect the application. Images should be configured to not run on the host system using the admin (root) account. This protects the host from privilege escalation if the application is compromised.

Images should be signed by a trusted certificate authority so they have a trusted signature that can be verified when the image is deployed to an environment. Images should be stored in a dedicated image repository so that all internal microservices platforms (Docker and Kubernetes) only pull “approved” images.

Test process

Testing is one of the first environments that an application build is deployed into. Testing teams use tools like Selenium and Cucumber to help automate as much of the testing as possible. Automated test plans can benefit from iterative improvements that increase the test plan quality every time a build is created. DevSecOps has open-source tools like ZAP that support proxying and can sit between the testing tools to perform security scanning as the tests are examining the application. Bringing DevSecOps and the testing teams together helps builds trust and collaboration while speeding up testing and reducing the number of scripts and tools necessary to complete the testing process.

Bending the rules

Outages, quality issues, and common mistakes can happen when there is pressure to deliver in a compressed timeframe. Building and testing is where bending the rules may be accepted or even the current norm within the teams. Security scanners are designed to stop the build process if audits and compliance fail. If the development and testing teams are unaware of this risk, it will appear as builds and tests breaking. They will complain to their leaders who will come to the DevSecOp team and demand the tools get out of the way of the success of DevOps.

DevSecOps overcomes these concerns by being an integral part of the team with developers and testers. Coordination between DevSecOps and developers is also promoted by adding the findings from these tools into the same bug tracking tools used by testers. DevSecOps integrates by speaking about the changes and listening to incorporate the feedback loop, create inclusiveness, and collaborate to help everyone understand what the tools are doing, how they work, and why they are important.

Next steps

Security scanners help developers follow secure-coding and license compliance practices. Scanners and feedback work best when performed as early as possible in the build pipeline so adjustments can be made quickly and with minimal development impact. Using automation encourages developers and testers not to bend the rules. With the application built and tests complete, the software is ready to be packaged as a release.

Read More

New vulnerability exploited most widely in Europe

Read More

When creating an application, programmers spend a lot of time anticipating what a user will need and how their application should react. The best programmers keep control using tight code while also planning for any contingency, but nobody can anticipate every possible action that a user might take. That is where fuzzing tools can come in very handy.

What is fuzz testing?

Fuzz testing is an automated process where a fuzzing engine attempts to send vast amounts of unexpected, erroneous or just random input into an application so that a programmer can see how it will react. They can then code appropriate responses that will protect the integrity and security of the application before it’s deployed to the public.

To read this article in full, please click here

Read More

If you are like me, you follow world events and news such as Okta being breached by a group of teenagers to see if you need to change your defenses. This may not be a time to roll out new technologies or major changes to your network, as this will introduce other types of risk. Instead, consider taking these steps in response to current events.

Block traffic selectively

Blocking traffic from Russia and Belarus may help you limit noise from your log files, and if you run a customer-facing website, from trolls and spam comments, but blocking their location will not slow a dedicated attacker. They will merely hop on another VPN and come in from another location. If you do want to reduce traffic, review your business needs and limit to those countries and locations that you do business with.

To read this article in full, please click here

Read More

Will your company’s decision and position on the Russian invasion of Ukraine or their continued presence in the Russian market (or exit from this market) carry with it the prospect of retaliation? The answer, unfortunately, is yes. Decisions, even to decide to do nothing and straddle the fence, carry  consequences. Even if the consequences are wrong-headed, unjust and unwarranted, individuals, governments and organizations will make their own interpretations.

I’ve spoken to the disruption in supply chains, to threading the needle on exiting or not exiting the Russian market due to Russia’s invasion of Ukraine. In addition, the U.S. government’s effort at outreach to ensure companies have the opportunity to digest and implement advisories being issued by CISA has reached a new level of both urgency and frequency.

To read this article in full, please click here

Read More

Seven alleged scammers arrested in Johannesburg

Read More