Data privacy automation company LightBeam.ai has launched a new AI-powered data privacy automation platform designed to help organizations streamline compliance. LightBeam said its new offering takes an identity-centric approach to allow customers to automate compliance against a patchwork of existing and emerging privacy regulations such as GDPR, CPRA, HIPAA and PCI DSS. The platform will be officially unveiled at the IAPP Global Privacy Summit 2022 in Washington, April 11-13.
Category Archives: News
New threat group underscores mounting concerns over Russian cyber threats
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.
DevSecOps build and test process
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.
What is the risk of retaliation for taking a corporate stance on Russia?
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.
Best advice for responding to today’s biggest cyber threats
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.
10 top fuzzing tools: Finding the weirdest application errors
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.
Almost a Fifth of Global Firms Targeted with Spring4Shell
South African and US Officers Swoop on Fraud Gang
Block Warns Eight Million Customers of Insider Breach
Three Years of Pay Parity: Lessons in Maintaining Equality
This month, McAfee celebrates three years of maintaining pay parity. Compensating employees equally for their contributions, regardless of gender or ethnicity, is one of the many ways we create a culture where all can belong and an environment where everyone is valued.
But equal pay sounds like a given, right?
It absolutely should be. However, unconscious bias and a slew of contributing factors, such as differences in how men and women negotiate pay raises and starting salaries, means inequality can slowly creep in across a business and become pervasive unless actively monitored. This means maintaining pay parity requires constant work and attention.
As the first cybersecurity company to achieve pay parity, we know first-hand the commitment involved in such an undertaking. We also know the overall impact for our employees, including greater trust, engagement, and loyalty. More than this, we believe simply, that pay parity is the right thing to do.
Today, I’m sharing more about our journey, our process, and our work to maintain pay parity.
How we began
Our pay parity journey began in 2018. Few companies had achieved pay parity at the time, but we realized it was an essential part of ‘walking the walk.’ It’s well documented that diverse teams perform higher, and when employees feel seen and valued for their contributions, they are more productive and increasingly innovative.
We developed a framework and conducted our first annual audit in 2018. When results revealed pay disparities across nine of our 45 countries, we were unwavering in our commitment to resolve swiftly and to put measures in place to maintain any pay parity drift over time.
Within six months, we spent $4 million adjusting salaries to achieve pay parity – this is something most companies undertaking this exercise take years to achieve.
Our process
In its simplest form, we adhere to the following framework for achieving and maintaining pay parity:
We define. Pay parity means fair and equal pay for employees in the same job code, grade level and location, regardless of gender or ethnicity.
We analyze. We first audit employee job codes for accuracy and then group employees by job code. We apply controls for pay differentiators such as performance, tenure, and experience.
We adjust. After meticulous evaluation with the business, we make any pay adjustments.
We uphold. In addition to annual analysis, we keep parity at the forefront throughout the year—from our hiring practices to how we promote and reward our employees.
Staying the course
Maintaining pay parity is a year-long exercise and is now part of our culture. At McAfee, we regularly run audits and use a third-party vendor to help remove any bias and subjectivity. If discrepancies are identified, we address them quickly.
We also work hard to keep pay parity front of mind for people leaders and hiring managers. Through regular training on diversity topics, we remind people leaders of the science behind unconscious bias and how to overcome it. To further remove any bias, we overlay promotions, awards, and relevant employee programs with a Diversity Impact Analysis to ensure allocation of awards is statistically aligned to the diverse population of that team or organization.
It’s the combination of these efforts that resulted in an exciting milestone: our latest independent audit revealed no disparity. This tells us our commitment to equality permeates our culture. The absence of any discrepancies did not happen by accident – it’s the result of intentional focus from our leaders, recruitment team, and hiring managers.
What the future holds
Since we began our journey three years ago, the world has experienced tremendous change and challenging times – some may feel more divided than united. This makes our commitment to pay parity and building an inclusive culture even more important.
We will continue to maintain parity, ask what we can do better, and share the best practices we continue to follow, as well as learnings along the way.
Ready to join a company that stands for equality? Search our openings at Careers.McAfee.com.
The post Three Years of Pay Parity: Lessons in Maintaining Equality appeared first on McAfee Blog.