Dimensional Data

Published December 11, 2020 WRITTEN BY THE KIUWAN TEAMExperienced developers, cyber-security experts, ALM consultants, DevOps gurus and some other dangerous species. Without a doubt, the COVID-19 pandemic has had a massive impact on the financial services landscape. Not only did businesses have to tweak their entire operations under safety regulations, but they also had to contend with a growing list of cybersecurity threat-actors, given the rapid adoption and usage of online apps.  According to data from App Annie, there was a 20% increase in time spent on mobile apps in the first quarter of 2020. At the same time, consumers embraced online banking, social media, and online shopping like never before. All of these created more cybersecurity risks. To avoid exploitation and compromise of sensitive data, information, technology, and security leaders need to view app security through a new pair of lenses. This should include a defense plan that considers the remote workforce, significantly reduced IT budgets, and limited access to AppSec talent.  Read on as we explore a dynamic plan to boost your cyber protection in a post-pandemic world.  1. Data breaches Mobile banking malware risk has worsened, especially now that bad actors leverage uncertainty and fear surrounding the pandemic. Recent research from Malwarebytes shows that mobile banking malware has spiked in recent months, infiltrating weakened home networks and mobile devices to access highly-sensitive corporate applications. These malware solutions are only focused on one job: stealing client information. What CIOs and CISOs can do: The best place to start is identifying and remediating the security vulnerabilities in your application before it’s too late.  Plan to conduct application security vulnerability scanning with a tool like Kiuwan. Remember, a data breach could set back the company some millions of dollars, which is why you should never leave your mobile app security to chance. 2. Identity theft Credential stealing has spread around the US almost as effectively as the COVID-19 pandemic. Since the bulk of the workforce has switched to working remotely, black-hat cyber criminals’ attacks have grown exponentially.  Credential theft is the leading cause of fraud in financial services, and with credential-stealing malware such as EventBolt19 and Cerberus being increasingly widespread in 2020, the risk has never been greater. What CIOs and CISOs can do: The post-pandemic world presents a new opportunity for CIOs to protect employees from the claws of identity theft. The best defense should focus on building authentication solutions that focus on ‘who you are’ rather than ‘something you have’ (passwords).  That said, consider installing next-level biometric solutions such as thumbprint/fingerprint, iris, voice, retina, and facial recognition technologies. With biometrics, cybercriminals’ attempt at impersonating anyone of your team members just got a lot more difficult than trying to break into passwords or PINs. 3. Ransomware attacks  Even after the pandemic, ransomware will remain one of the most significant cyber threats facing financial institutions. Statistics show that financial services will still be the second most targeted sector for ransomware attacks, only trailing healthcare. Successful ransomware attacks reveal not only endpoint vulnerabilities but also act as a starting point for myriad other problems. For example, a breach could lead to huge monetary loss. But most importantly, businesses that don’t proactively protect against attacks will likely suffer from damaged loyalty and reputational risk. Yet this is only the tip of the iceberg. Other repercussions of ransomware attacks are weakened employee morale and the need to dig deeper into […]

Published December 9, 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. Cybersecurity is getting a lot of attention, from the break room to the board room. Few weeks pass without another salacious story in the media about a new large-scale data breach, ransomware outbreak or other attack designed to disrupt normal life.  Cybercriminals know what they are doing, and they’re able to succeed in their goals with uncomfortable regularity. Those goals are increasingly focused on enterprise applications due to the large number of access opportunities that are supposed to support end-users and internal personnel. For example, last year 62 US colleges were targets of cyberattacks that exploited their enterprise resource planning (ERP) system vulnerabilities. Cybercriminals constantly search for easy targets. Expanding complexity, growing numbers of users and partners, and rapidly emerging exploits make security an elusive target. Learning about the most common security gaps found in software, why those gaps really matter, and how to close them can make you less likely to be the next big victim. Instead of approaching security by being as secure as you can be, a better approach is to just be as secure as you need to be. That’s a subtle difference, but the outcome of the latter can be similar to the goal of the former, with much less effort and expense. Let’s cover some rudimentary aspects of security and a basic approach that balances security with budget and effort.  The lure of low-hanging fruit In this article I’m focusing on general cybercriminals who are looking for financial gain. They don’t care who their next victim is. Other types of cybercriminals, such as disgruntled (possibly former) personnel, “hacktivists,” or other people who are targeting your specific data or intellectual property are more determined and motivated to succeed. But here, we’re talking about cybercriminals looking for any victim, so they mainly want a quick and easy attack. Using the path of least resistance is a good thing. The easiest and cheapest path to the bottom line is most commonly the desirable path. Of course, there are reputational impacts and other obstacles that affect the decision-making process, but there is always some appeal to the path of least resistance. Cybercriminals spend a lot of effort identifying the easiest targets. What does this have to do with your security? One important key to being as secure as you need to be is simply avoiding being a hacker’s “low-hanging fruit.” Most cybercriminals use automated scanners to find potential victims they can attack without much work. They look for well-known vulnerabilities that their potential victims haven’t addressed. Cybercriminals know that keeping security controls current takes time and effort, and many organizations have “more important” tasks than hardening systems and networks. This gap between known vulnerabilities and implemented controls defines the sweet spot that cybercriminals are looking for. The best defense from most cybercriminals is to just be secure enough to not be worth their effort. This approach to cyber defense simply means that you should learn about the most common vulnerabilities and fix those first. If you have more budget to go further, that’s great. But at […]

Published December 2, 2020 WRITTEN BY THE KIUWAN TEAMExperienced developers, cyber-security experts, ALM consultants, DevOps gurus and some other dangerous species. As business management expert Peter Drucker once put it: “If you can’t measure it, you can’t improve it.” This quote feels right in place in the world of application security. Many CISOs are finally starting to give SAST tools and other approaches the attention they deserve. However, the only way to know if your approach works is by using app security and quality analytics.  While there are many security metrics you can track and assess, choosing the ideal ones for your company is of paramount importance. It’s the best way for CISOs, developers, and other stakeholders to gauge the application’s effectiveness and improve its efficiency. Why Application Security Analytics Matter Arguably the most important part of any application security plan is determining the key data analytics to track. For instance, many CISOs want to see a drop in the number of new malware attacks targeting an application (making this an important analytic to track). A drop in this figure over time shows an improvement in secure coding practices within the team. Allowing your security professionals to have access to real-time analytics is also important. It goes a long way to improving their efficiency.  Some of the analytics they should access with ease includes: Data regarding the type of threats being identified How they are discovered And the time it takes to remedy them.  Another thing to remember is that there is both direct and indirect analytics you can track. Direct analytics gauge the security of the program itself, such as the exact number of known threats. Indirect analytics go above and beyond the program and, instead, target practices, tools, and people. A blend of direct analytics and indirect analytics paints the most accurate picture of how your application security (AppSec) tools work. Without these analytics, CISOs will attempt to secure their programs blindly, with limited capacity to deliver quality business outcomes. Six AppSec Analytics To Improve Application Security & Quality 1. Total number of application threats and their severity This is arguably the most vital application security and quality metric for your organization.  It’s prudent to know the exact number of weaknesses present in an app, and more importantly — just how severe each threat is. Severity depends on the effect the weakness can have on the app (and the company at large) and how often it is likely to happen. The best way to pinpoint the biggest weaknesses is to leverage the outcomes from Dynamic Application Security Testing (DAST) tools and Static Application Security Testing Tool (SAST) tools like Kiuwan. Click here to read more about these testing tools. SAST tools single out potential threats in the source code, while DAST tools show you which of these weaknesses can actually lure attackers. Leveraging results from both SAST and DAST tools will enable you to draft a list of the weaknesses that pose the most significant threat to the program. Better yet, your team can use these analytics to identify issues that require immediate remediation. 2. Number of new threats detected In agile software development, new releases and updates are quite common. It’s vital to know the exact number of new threats discovered when a program is deployed. This analytic helps CISOs keep better track […]

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