Dimensional Data

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). […]