Dimensional Data

Published November 25, 2020 WRITTEN BY MICHAEL SOLOMON Michael G. Solomon, PhD, CISSP, PMP, CISM, PenTest+, is a security, privacy, blockchain, and data science author, consultant, educator and speaker who specializes in leading organizations toward achieving and maintaining compliant and secure IT environments. Most people involved in the process of creating and deploying software applications today are familiar with DevSecOps, which integrates security and operations into the software development process. In figurative terms, we think of the software development lifecycle as a timeline, starting with the design on the left and the deployment (and post-deployment activities) on the right. Historically, security was overlooked until as late as possible in the process; it was something to consider once you had a viable product. But the truth is, ignoring security early on makes it harder and more costly to add on later. As DevSecOps continuously pushes security “to the left” in the software development process, autonomous assessment can provide assurance of security compliance from development’s earliest stages. One type of autonomous assessment, static application security testing (SAST), can help identify software flaws early on. Let’s explore how using SAST helps DevSecOps achieve its stated goals while minimizing friction. What SAST offers Experienced software developers can integrate correctness, robustness, efficiency, elegance and even security into the code they create. However, even the best developers don’t get it right every time. And less experienced developers tend to deviate from standards and best practices in order to get the job done. In today’s push to deliver products quickly and efficiently, it gets harder and harder to pay attention to all the details, including security. SAST can provide a valuable tool in the software developer’s toolbox for writing quality code. Far from some initial developers’ perception, SAST isn’t just one more hoop to jump through. Strategically laced SAST assessments can alert developers and management that potential flaws exist and should be addressed early in the process. Developers commonly find that SAST helps them to be more efficient. The last thing you want to find is a critical design flaw that stays hidden until the final testing before release. SAST can increase the likelihood you’ll find flaws long before they get “baked in.” One great way to leverage SAST’s value is to require assessment of all code before the initial check-in. You don’t (or shouldn’t) ever commit code that doesn’t compile, so why should you be able to commit code with security flaws? Find the flaws and fix them before committing work to the pipeline. Instead of increasing each developer’s workload, you’ll decrease (in many cases dramatically) the time required down the road in rework to fix flaws someone else finds. Plus, complete SAST codebase scans may take hours. Individual and small-batch scanning is much faster. Requiring developers to carry out SAST scans locally distributes the overall workload and reduces friction along the development pipeline. Although giving individual developers the ability to automatically flag potential issues is a huge benefit, management and auditors enjoy SAST’s help in doing their jobs as well. Developers can fix flagged issues before committing code, but some errors won’t be found until more comprehensive tests, including integration tests, get carried out. For example, pre-build SAST assessments may identify flaws that unit-based SAST assessments couldn’t see. Each time SAST identifies new flaws, management has […]

Published November 18, 2020 WRITTEN BY ED TITTEL. Ed Tittel is a long-time IT industry writer and consultant who specializes in matters of networking, security, and Web technologies. For a copy of his resume, a list of publications, his personal blog, and more, please visit www.edtittel.com or follow @EdTittel Open source software is essential to application development, particularly for the web. At the same time, it also represents a key source of application vulnerabilities. To help make open source software more secure, the Linux Foundation has announced a cross-industry collaboration with open source leaders including GitHub, Google, IBM, JP Morgan Chase, Microsoft, Red Hat, the OWASP Foundation, and others. This collaboration is called the Open Source Security Foundation, or OpenSSF. In an August blog post, Microsoft Azure CTO Mark Russinovich explained the OpenSFF’s impetus and mission as follows: Open source is everywhere and essential for just about every company’s strategy Securing open source is essential to security the supply chain for all parties, including Microsoft itself Because open source software is so widely used, attackers can exploit many vulnerabilities. These cover most critical services and their supporting infrastructures, across industries such as utilities, healthcare, transportation, government, and IT (especially traditional software, cloud services and IoT) The community-driven nature of open source software means no central authority is responsible for its quality control and maintenance Because open source code may be copied and cloned, versioning and dependencies are particularly complex and can be hard to follow Open source is vulnerable to developer attack, wherein attackers can become maintainers of open source projects and introduce malware Given all these factors, especially how complex and intertwined open software can be, it’s fair to say that building and securing open source software must be a community-oriented and -supported effort. The OpenSSF home page states that its first group of technical initiatives will include the following areas of focus:  Vulnerability Disclosures Security Tooling Security Best Practices Identifying Security Threats to Open Source Projects Securing Critical Projects Developer Identity Verification The site also offers related security resources from the OSSC ( an analysis of the Open Source ecosystem in pdf format), the Linux Foundation’s CII  (a discussion of vulnerabilities in the Internet core), and Red Hat’s Product Security Risk Report, to help readers get started on understanding open source threats and mitigation approaches and strategies. The OpenSSF GitHub repository is also likely to be of great interest. What is the Kiuwan response to the formation of the OpenSSF? Kiuwan welcomes the formation of the OpenSFF and Microsoft’s participation and leadership role in that initiative. Because open source is such an important part of application development, the Kiuwan team is excited to see community initiatives that are focused on improving the security of open source projects. Information and collaboration are key tools in combating the proliferation of security threats. Kiuwan solutions currently supports OWASP, the Open Web Application Security Project, as well as FS-ISAC, the Financial Services Information Sharing and Analysis Center, and is open to additional opportunities for promoting application security. How does Kiuwan acquire open source software vulnerability and security data? Kiuwan draws its OSS data primarily from the NIST NVD (National Institute of Standards and Technology’s National Vulnerability Database), with a handful of additional feeds. How does Kiuwan obtain implementation recommendations and best practices […]

Published November 11, 2020 WRITTEN BY ED TITTEL. Ed Tittel is a long-time IT industry writer and consultant who specializes in matters of networking, security, and Web technologies. For a copy of his resume, a list of publications, his personal blog, and more, please visit www.edtittel.com or follow @EdTittel Simply put, threat intelligence – also known as cyber threat intelligence, or CTI – is information that is collected, analyzed, organized, and refined to provide insight, input, and advice about potential and current security threats or attacks that could pose potential or actual risks to an organization. CTI covers a wide range of information sources and can involve reports of attacks obtained from security telemetry in cybersecurity software, from researchers conducting experiments, and even from automated security testing tools (e.g. fuzzing) that automate repeated variations on accepted or expected inputs into systems and software. Threat intelligence feeds: free and open source Gathering and providing threat intelligence often occurs in the form of various “feeds.” These are continuous, ongoing streams of data about threats that incorporate information items about newly-discovered threats along with updates and amendments to information about known existing threats. Threat intelligence feeds are an important part of modern cybersecurity best practices, and may include information about countering or working around individual threats (often called “remediation advice”). In general, threat intelligence feeds fall into two broad categories. First and most widely consumed are those identified as free or open source security feed options. These are available to all interested parties and may be consumed without incurring costs for their uptake and use (though they are subject to licensing conditions about which prospective consumers should make themselves aware). Searching the Web for “best open source threat intelligence feeds” is a good way to identify such things, given that there are hundreds of such feeds from which cybersecurity service and software providers and interested organizations can choose. Here’s an example “Top 10 List” from D3 Security: Kiuwan draws much of its Open Source Security data from the NIST NVD (National Vulnerability Database), which is another widely-used and -respected free and open source security feed. Threat intelligence feeds: commercial options Working with free, open source intelligence feeds involves a wide-open, no-holds-barred outlook on converage, content, and quality. Working with such feeds requires a fair amount of work to separate the wheat from the chaff – that is, to filter out inputs and information that is not relevant to the exposures and vulnerabilities actually present in one particular organization or another. Commercial CTI feeds let customers – who can pay upwards of US$1,500 a month per feed for such access – establish and maintain filtering criteria to make sure they see only information of direct and immediate relevance to the hardware, software, and systems present in their organizations. According to Technology Comparison and Rating company CompariTech, the top 6 such producers  are as follows: The interesting thing about threat feed consumption is that most such feed come in multiple tiers – at progressively higher monthly costs – and really target enterprise-scale organizations and security service and software providers. Unless you have a team of security researchers and analysts (and a sizable budget to support their direct and indirect costs – including commercial security feeds) this will be more than most organizations are willing to […]

Published November 4, 2020 WRITTEN BY ED TITTEL. Ed Tittel is a long-time IT industry writer and consultant who specializes in matters of networking, security, and Web technologies. For a copy of his resume, a list of publications, his personal blog, and more, please visit www.edtittel.com or follow @EdTittel It’s always fun to start throwing out acronyms to get one’s technical juices flowing. To make sense of this blog post title, readers show know that OWASP is the Open Web Application Security Project, and that the ASVS is the Application Security Verification Standard. Of course, making sense of what this all means calls for additional explanation and more information. Let’s start with a brief backgrounder on the OWASP and follow up with a closer look at the ASVS with special emphasis on what it does and why it’s important. Introduction to the Open Web Application Security Project (OWASP) Founded in 2001, and incorporated as a US non-profit charity in 2004, the OWASP is an open community that’s focused on helping organizations design, develop, acquire, operate and maintain applications – especially web-based applications – that are secure and trustworthy. The OWASP’s reach covers a lot, including: Dozens to hundreds of community-led open-source software projects 275-plus local OWASP chapters around the globe Tens of thousands of registered OWASP members (individuals and organizations) Popular, widely-followed and -attended education/training conferences All OWASP projects, tools, documents, forums and chapters are free and open to those interested in improving application security. Overview of the Application Security Verification Standard (ASVS) The ASVS defines a basis for testing web application technical security controls (these are features or elements of an application designed to provide authentication and manage identity data, control access, provide data privacy and protection, and so forth). ASVS also equips developers with a checklist of requirements to ensure secure development practices and procedures, and to ascertain they produce secure code. As standard, the ASVS seeks to provide guidance, metrics and evaluation criteria for secure applications. In the area of guidance, the ASVS offers instructions and information to those who develop security controls on what must be built into such controls to meet application security requirements. In the area of metrics, the ASVS provides a yardstick of sorts against which to assess the degree of trust that applies to their web applications and development efforts. In the area of evaluation criteria, the ASVS works when procuring web applications from third parties to provide a basis for specifying (and enforcing) application security verification requirements in purchase agreements and contracts. As of November 4, 2020, the latest version of the ASVS is 4.0.2. It is available for download from GitHub. The release comes in .ZIP and tar.gz formats, and is approximately 60 MB in size (compressed; ~100 MB uncompressed). The Standard document itself is included in that archive, along with a test runtime. Who uses ASVS? The ASVS page includes an ASVS Users tab that names a variety of companies and agencies that have incorporated this standard into their software assurance toolsets. These include the following: What makes ASVS important for application security? Simply put, ASVS creates a common set of terms and metrics, along with a shared platform so that software developers and engineers can create secure working environments for web applications. The ASVS checks their efforts to […]

Published October 27, 2020 WRITTEN BY THE KIUWAN TEAMExperienced developers, cyber-security experts, ALM consultants, DevOps gurus and some other dangerous species. We’re excited to announce that Kiuwan Code Security and Insights solutions have been recognized in the Fall 2020 G2 Grid Report for Static Code Analysis, due in large part to an overall customer satisfaction rating of 4.4 out of 5. What is the G2 Grid Report?  G2 is a comparison platform for business solutions. The G2 Grid report analyzes leading solutions in an industry based on market presence and customer satisfaction. To determine a vendor’s market presence, G2 uses a combination of more than 15 data points from G2’s user reviews, publicly available information, and third-party sources. For the customer satisfaction rating, G2 Crowd analyzes the reviews submitted about a product in several areas. In addition to receiving a 4.5 out of 5 rating overall to earn the “Users Love Us” badge, Kiuwan was recognized in the following areas: Fastest Implementation: for having the shortest go-live time in the Static Code Analysis category. Highest User Adoption: for having the highest User Adoption rating in its category. Easiest Admin: for having the highest Ease of Admin rating within the Usability Index of the Static Code Analysis category. High Performer: according to G2, “products in the High Performer quadrant in the Grid® Report have high customer Satisfaction scores and low Market Presence scores compared to the rest of the category.” What this means is that Kiuwan is a great product, but not as well known as other solutions in the industry (yet!). What do Kiuwan users have to say? Kiuwan users have submitted over 20 reviews on the G2 platform. Below are some of the comments they shared about their experience with Kiuwan solutions: Rosnel A.: I like how you can handle and move around the environment handling the definition and indication of where the correction should be applied. Many people do not have this access and cannot handle this type of information. But for the company, it was very important. I also really like the great color that the environment has. This helps a lot to be able to detect with priority which problem I should tackle first. I also quite liked the easy integration with Jenkins. For me, this was quite important. The use of additional parameters and all parameters. I also liked how the projects can be separated to group the reports. Jose Luis M.: What I like the most is being able to launch the analysis locally without having to wait for the analysis queues. It is also very easy to configure and create your own rules. Oscar G.: Kiuwan is a powerful tool that helps our developers to create secure software. Also, the code quality component is very good. It provides a lot of information on governance and it has support for many languages and frameworks. It’s well integrated with other tools like development environments or continuous integration tools like Jenkins. You could integrate easily Kiuwan in your SDLC. The Kiuwan support team is very effective. Visit the Kiuwan page on G2 for additional verified reviews from real users, or to submit your own review! Would you like to know more about implementing a Static Code Analysis solution in your company? Get in touch with our Kiuwan team! We […]

Published September 23, 2020 WRITTEN BY THE KIUWAN TEAMExperienced developers, cyber-security experts, ALM consultants, DevOps gurus and some other dangerous species. The Kiuwan team is excited to announce the availability of our latest release, featuring extended support for JSX React, the ability to check for dynamic components built using an Angular framework; and an updated plugin for Jenkins. Angular dynamic components  We’ve expanded our JavaScript support with this release. Now, Kiuwan is able to check for dynamic components built in an Angular framework. The underlying vulnerability from using dynamic component construction is identical to other types of “eval injection” issues, as described in the description of CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval Injection’). Dynamic component construction makes it possible for an attacker to attacker to “execute arbitrary code, or at least modify what code can be executed,” potentially giving the attacker full control of the browser environment. JSX React Previously, Kiuwan’s JavaScript implementation provided partial support for React. Now, this support is extended with JSX technology. JSX, or JavaScript XML, is an XML-like syntax extension to ECMAScript part of the React library. The complete specification is available at Draft: JSX Specification. The following elements have been identified as potential security flaws and are detected by the existing JS rules: The dangerouslySetInnerHTML attribute acts as the entrance door to perform an XSS attack (See dangerouslySetInnerHTML). Server-side rendering attacker-controlled initial state XSS in React apps using Redux. XSS in explicit calls to React.createElement(…) with untrusted props or children (See Avoiding XSS in React is Still Hard). Attribute injection also leads to XSS. In React, the HTML code is embedded into the JS code, so the HTML code must be checked to mark sources, sinks, or neutralization (For example: elements). Also, the embedded HTML code is analyzed by Kiuwan with the rules from the HTML technology. The following existing checks may be applied: OPT.HTML.AutocompleteOnForSensitiveFields. OPT.HTML.MissingPasswordFieldMasking. OPT.HTML.TargetBlankVulnerability. OPT.HTML.SandboxAllowScriptsAndSameOrigin. OPT.HTML.SpecifyIntegrityAttribute. Kiuwan plugin for Jenkins update The Kiuwan Plugin for Jenkins allows you to execute a Kiuwan analysis as a Post-build action or as a Pipeline step.  For full documentation or to download the plugin, refer to the links below: In this release, we’ve updated the Kiuwan plugin for Jenkins as described below: Connection Profiles: Previously, Kiuwan Jenkins Plugin’s connection settings were limited to one configuration per Jenkins installation. Now, you can set several profiles, you can use multiple accounts, and Kiuwan On-Premises customers may use different environments.  New analysis result dashboard. Improved support for short-lived nodes. Pipeline support. Additional bug fixes and improvements For a full list of additional bug fixes and improvements, refer to our Change Log.

Published September 30, 2020 WRITTEN BY MICHAEL SOLOMON Michael G. Solomon, PhD, CISSP, PMP, CISM, PenTest+, is a security, privacy, blockchain, and data science author, consultant, educator and speaker who specializes in leading organizations toward achieving and maintaining compliant and secure IT environments. Developers often pursue well-intentioned security efforts by focusing on writing secure code. But that’s just part of the puzzle. Instead of focusing only on the code, it’s just as critical to focus on the attacker. Understanding how attackers compromise controls changes the way developers think about security. A revealing question is: “How could an attacker use my code for malicious purposes?” Thinking in this way changes the whole development perspective. The general process of assessing vulnerabilities in software from an attacker’s point of view is commonly referred to as threat modeling. The main purpose of threat modeling is to assess an application and its surrounding environment to find as many vulnerabilities as possible before attackers do. Threat modeling isn’t new; mature development organizations have been threat modeling for a couple of decades. One of the earlier approaches to formal threat identification was the idea of “threat trees,” introduced by Edward Amoroso in 1994. A similar early view came from Bruce Schneier in the form of “attack trees.” Both approaches use conceptual diagrams to illustrate how a target might be attacked. Microsoft was an enthusiastic early adopter of formal application development threat modeling and introduced the STRIDE approach. A few years later an operations-centric approach, OCTAVE, was introduced. Today, threat modeling is finding renewed interest as organizations move toward DevSecOps approaches. Some may consider threat modeling an artifact from the ’90s, but the philosophy fits well into current development approaches. Introducing threat modeling to a DevOps team Traditionally, threat modeling is an application design activity. However, solutions are emerging that use testing and post-deployment behavior to feed threat modeling analysis. In short, threat modeling has moved from application design to include operations. That means DevSecOps can benefit at all phases from comprehensive threat modeling. Expand your thought boundaries Remember, DevSecOps is a culture, not an organization. It’s all about removing isolation and barriers that tend to compartmentalize activities and valuable information and reduce both efficiency and quality. Prior to DevOps or DevSecOps, most organizations created silos of process and information and protected the integrity of those islands. That’s not to say that silos were created exclusively with selfish intent; silos tend to be self-preserving and naturally occurring. But in reality, breaking down silos leads to better communication, higher product quality, and more longevity. Sharing tribal knowledge and using it to “sand down the rough edges” of a product or service makes the entire development process better and customers happier. This requires change, and while change may be good, it often isn’t fun. Resistance to change tends to be one of the most difficult barriers to clear in any project. You must convince the stakeholders that the proposed change is worth the effort. In short, you have to change the culture of the comfortable norms.  Change for the sake of change doesn’t get you very much. But change to pursue growth can be satisfying and rewarding. It is the latter type of change that makes threat modeling a good fit for a DevSecOps organization. The two philosophies work well together.  […]

Published October 6, 2020 WRITTEN BY THE KIUWAN TEAMExperienced developers, cyber-security experts, ALM consultants, DevOps gurus and some other dangerous species. October is Cybersecurity Awareness Month. The theme for 2020 is: “Do Your Part. Be #CyberSmart.”  This event, put on by CISA and the National Cyber Security Alliance, is in its seventeenth year. The campaign aims to increase overall cybersecurity awareness, helping both private individuals and companies develop a safer, more secure environment for both themselves and their customers. This year’s “Do Your Part” theme encourages each individual to take a proactive approach to improve overall security.  Why have a “Cybersecurity Awareness Month”? The internet and an online identity have become increasingly important parts of the world. Most people are now connected in some form. Businesses rely on that connectivity to do business. A lack of cybersecurity, however, can open up both businesses and personal individuals to potential attacks.  Unfortunately, much of the world failed to recognize those potential threats even as they embraced the opportunities offered by the internet and connectivity. In 2004, CISA and the National Cyber Security Alliance decided that it was time to start spreading awareness. Out of that, National Cybersecurity Awareness Month was born. The program aims to increase public knowledge about the potential threats both businesses and private individuals can suffer based on the information they place online. Many people simply do not recognize the errors they commit every day, from insecure passwords to failing to take the right measures to protect their devices. Organizations fall victim to phishing scams every day because employees fail to recognize them for what they are. By increasing awareness, both within organizations and across social media and other popular platforms, National Cybersecurity Awareness Month helps keep businesses and individuals safer online. What’s behind the theme: “Do Your Part: Be #CyberSmart”? Many cybersecurity professionals acknowledge that the greatest threat to most organizations isn’t a threat from the outside. It’s the employees. Phishing attacks, for example, remain at the top of the list of potential challenges that many organizations face each year. Unfortunately, in order for phishing attacks to be successful, an employee must make an error: giving out confidential information, clicking an insecure link, or otherwise giving a scammer a window into the organization. By encouraging each person to do their part, this year’s Cybersecurity Awareness Month theme encourages personal accountability for each member of the team. Securing a company requires commitment from all of its employees. Proper education and awareness, however, can go a long way toward improving organization security.  What events are planned for Cybersecurity Awareness Month? Cybersecurity Awareness Month is dedicated to improving cybersecurity awareness and organization across the United States. It’s a national event, celebrated by tech companies and companies interested in improving technical awareness alike. Each week, Cybersecurity Awareness Month focuses on a different topic: Week of October 5 (Week 1): If You Connect It, Protect It: A look at what devices really need to be protected and how the Internet of Things can have a powerful impact on your office environment.  Week of October 12 (Week 2): Securing Devices at Home and Work: With more employees than ever working remotely, it’s important to consider what you can do to protect devices on your home network–as well as providing additional security when those devices […]

WRITTEN BY THE KIUWAN TEAMExperienced developers, cyber-security experts, ALM consultants, DevOps gurus and some other dangerous species. According to a report from IBM just a few years ago, as many as 50% of companies had no budget for mobile app security. This is especially worrying because, in the first half of 2019 alone, there were data breaches that exposed around 4.1 billion records. A more recent study also showed that 3 out of 4 apps leaked sensitive data that exposed users to fraud and identity theft. Incidences of app data breaches are increasing at an alarming rate, undermining consumer trust in mobile app safety. App users trust you enough to share their sensitive data on your platform, and the responsibility of ensuring the app is secure falls on leaders of mobile app development teams. This begs the question, how do you ensure that the users of your app are protected against data breaches? Here are 8 approaches to securing your mobile application. 1.  Add an extra layer of security to the login process The Verizon 2019 Data Breach Investigations Report showed that approximately 80% of all data breaches occur due to weak credentials. This is why you need to put identification, authentication, and authorization measures in place. Use authorization technology or adopt the 2FA (two-factor authentication) method to add an extra layer of security to the login process. Biometrics such as fingerprints and retina scans are some recent authentication methods, which are more reliable than the 2FA. You should also encourage your app users to set strong passwords and update them regularly or ask the developers to design the app to only accept strong alphanumeric passwords. 2.  Conduct vulnerability testing If hackers were to attack your app today, how well would it hold up? No one ever thinks that their app could be a hacker’s target — until it is. As part of a mobile development team, you are bound to be biased and are wired to assume that your app is extremely secure. However, you should never leave mobile app security to chance, which is why you should conduct vulnerability testing periodically. Identify all security loopholes in your app’s infrastructure and fix them before it’s too late. You will require an effective application vulnerability scanning with a tool like Kiuwan, which supports Swift, Java, Kotlin, and Objective-C. 3.  Secure your app’s code from the ground up Your app’s security doesn’t begin after deployment of the application; it should be part of the development process. Make security a priority and protect your code from vulnerabilities that are often caused by developer error or lack of testing. To protect your mobile app’s code, keep it encrypted through minification and obfuscation coupled with API encryption. Run source code scanning and ensure that your security measures don’t affect the user experience and the app’s performance. 4.  Implement a good data encryption policy Ensure that all data being exchanged on your app is encrypted. This way, even if hackers get past your security, they won’t access any sensitive information. Avoid storing sensitive data on mobile devices or on your servers, and if it’s necessary, keep the data storage to an absolute minimum and in an encrypted format. For instance, the iOS keychain contains encrypted data storage.   If you keep logs, make sure they are […]

Published October 20, 2020 WRITTEN BY ED TITTEL Ed Tittel is a long-time IT industry writer and consultant who specializes in matters of networking, security, and Web technologies. For a copy of his resume, a list of publications, his personal blog, and more, please visit www.edtittel.com or follow @EdTittel Simply put, firmware is low-level software usually stored in a near-silicon form (ROM, EEPROM, or flash memory) that is used during the initial steps of bootstrapping and starting up a computer, printer, or some other kind of electronic device. Alternatively, firmware may serve to drive device-level communications with other components in a computer or other electronic device. Well-known instances of firmware include BIOS, UEFI, codes in audio devices or components, and so forth. Where there’s firmware, there’s often microcode as well… According to an ancient (1967) Datamation article firmware also describes a writable control store (a specialized limited set of high-speed memory locations) that contained so-called “microcode” to define and implement a computer’s instruction set. This is what drives instructions that CPUs can execute, and can be reloaded to update, specialize or modify the current instruction set. Firmware thus sits between hardware (the registers, processing units, busses, and so forth) and binary code (software instructions that have been translated into machine instructions for step-by-step execution). This is often called microcode and basically provides the irreducible elements in a CPU (or other processor) that supports individual machine instructions. Because firmware sits between hardware and software and is neither of those things, it’s long been called firmware. These two early and well-publicized microcode vulnerabilities appeared in 2017/2018 Because microcode may be updated or modified, it can also be attacked Over the past 4-5 years, for example, Intel processors have shown themselves susceptible to numerous, colorfully named microcode attacks. Two early instances of such attacks include Meltdown, aka Rogue Data Cache Load, identified as CVE-2017-5754; and Spectre, identified as CVE-2017-5715. Meltdown, if foisted, can sever the isolation normally maintained between user applications and the OS, allowing programs to ransack all memory on a compromised device. Spectre is similar, but enables attackers to force normally secure, error-free applications into leaking memory contents (secrets) to other applications. Thus, a malicious application could then “sniff” memory from normally secure code without throwing errors or other means of detection. There are many more such vulnerabilities now known in the wild. As recently as September 1, 2020, Intel published a Microcode update for a broad range of its processors that covered 4 additional microcode vulnerabilities, to wit: CVE-2019-11091 – Microarchitectural Data Sampling Uncacheable Memory (MDSUM) CVE-2018-12126 – Microarchitectural Store Buffer Data Sampling (MSBDS)? CVE-2018-12127 – Microarchitectural Load Port Data Sampling (MLPDS) CVE-2018-12130 – Microarchitectural Fill Buffer Data Sampling (MFBDS) Where the danger in firmware/microcode vulnerabilities lies Firmware (and microcode) operate at the lowest level within the devices they inhabit. They take up residence before a BIOS or OS starts up, and operate outside their purview and control. If an attacker can foist a firmware or microcode exploit, there’s very little runtime software can do to counter (or even detect) its presence and behaviors. Thus, a successful firmware or microcode exploit usually gives an attacker free rein and unlimited access to a compromised device (though they may also need direct access to that device to foist the exploit, or take advantage of its abilities). […]