devopsy.kinsta.cloud

Category: IT Security

  • OpenSSF Adds Open Source Package Analysis Tool Prototype

    OpenSSF Adds Open Source Package Analysis Tool Prototype

    The Open Source Security Foundation (OpenSSF) has made available a prototype of a package analysis tool that has already identified more than 200 malicious packages uploaded to PyPI and npm software components.

    Caleb Brown, an OpenSSF maintainer of the project, said the goal is to understand the behavior and capabilities of packages available on open source repositories. It also tracks how packages behave over time to make it easier to identify when previously safe software began to act in a suspicious manner.

    Most of the malicious packages detected are employing dependency confusion and typosquatting techniques, Brown said. They usually contain a simple script that runs during installation and provides a few details about the host to an external command-and-control system. Most of these packages are not exfiltrating meaningful data except the name of the machine or a username, but they make no attempt to disguise their behavior. The issue is that any one of these packages could have done far more damage, noted Brown.

    Future goals for the project include detecting differences in package behavior over time; automating the processing of the package analysis results; storing the packages themselves as they are processed for long-term analysis and improving the reliability of the pipeline. As such, the OpenSSF is looking for application developers and cybersecurity researchers to contribute to the project. The expectation is that many providers of application security tools will incorporate the package analysis tool within their offerings rather than requiring each vendor to create their own version of the same tool, said Brown.

    The OpenSSF has launched a series of initiatives to improve the overall state of open source security. Most recently, it added an Alpha-Omega Project to automate security testing processes for open source software using a $5 million initial investment provided by Microsoft and Google. The core challenge is that many organizations are dependent on open source software projects created and maintained by just a handful of volunteer maintainers and contributors. The individuals that created those projects don’t always have a lot of cybersecurity expertise. In fact, many of them would argue that the onus for securing open source software is on the organizations that use what amounts to free software. It’s not the responsibility of the contributors and maintainers to, for example, drop everything and immediately create a patch to address a zero-day vulnerability.

    It’s not clear how easily open source software could be compromised by cybercriminals that insert malware into downstream applications that rely on that code. However, in the wake of a series of high-profile breaches, it’s safe to assume that more cybercriminals than ever are trying to compromise open source software projects. While some organizations may opt to limit their dependency on open source code that has not been properly vetted, there is no way to entirely avoid using open source code. The challenge is finding a more efficient way to ensure the integrity of that code for all concerned.

  • Checkmarx Report Highlights Need for AppSec Collaboration

    Checkmarx Report Highlights Need for AppSec Collaboration

    A research report published by Checkmarx finds the same basic malicious software developed using multiple programming languages as cyberattackers industrialize their malware development processes.

    Checkmarx, a provider of code scanning tools, shared examples of malicious packages written in multiple programming languages. These example packages share the same indicators of compromise that have gone undetected for years. A “junkeldat” PyPI package for Python applications, for example, that has been compromised also shows up in a Ruby version of the package.

    Tzachi Zornstain, head of supply chain security for Checkmarx, said much like any other development team that uses multiple programming languages, it appears cybercriminals are also sharing techniques. These examples highlight the need for development teams to share security intelligence even if they build applications using different programming languages, he added. There is a tendency for development teams using one programming language to ignore application security issues that appear to only impact applications written in another programming language, noted Zornstain.

    The fact that the packages remained undetected for such a long period of time is due—at least in part—to the lack of information sharing in the ecosystem, said Zornstain.

    Cyberattackers are, of course, trying to take advantage of the implicit trust many development teams have in open source projects. However, now that more cybercriminals are making a concerted effort to compromise downstream software components, it’s imperative that every component be vetted, said Zornstain. In fact, organizations should not use any code provided by strangers, he advises.

    The core issue is that many open source projects are maintained by a small number of programmers contributing their time and effort to building components that others are free to use. Many of them argue that the onus for making sure software is secure is on the organizations that decide to deploy that software. Nor is it their responsibility to keep track of cybercrimimals distributing malicious versions of their software.

    Unfortunately, many IT vendors and large enterprise IT organizations that rely on that code are, unfortunately, not contributing anything meaningful back to the project, either in terms of financing or helping open source maintainers find and remediate vulnerabilities. Many of those same organizations, however, are assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions. As a result, it may be only a matter of time before these long-simmering open source software security concerns boil over into a larger crisis.

    One way or another, DevSecOps best practices will need to be applied to application development at a deeper level. Organizations can’t assume that the software components they are relying on have been scanned for vulnerabilities by someone else. It’s simply too easy for a development team to make a mistake. The need for higher levels of security may lengthen the development process, but the alternative—malware infestations wreaking havoc—is far less desirable.

  • Synopsys Sets Course After Agreeing to Acquire WhiteHat Security

    Synopsys Sets Course After Agreeing to Acquire WhiteHat Security

    Synopsys, Inc. plans to add dynamic application security testing (DAST) tools to its software-as-a-service (SaaS) platform in the wake of agreeing to acquire WhiteHat Security from NTT Security Corp. for approximately $330 million in cash.

    Jason Schmitt, general manager of the Software Integrity Group at Synopsys, said the DAST tools developed by WhiteHat will complement the existing static, interactive and software composition analysis tools that Synopsys currently provides.

    The goal is to provide an end-to-end application security platform, including consulting, to help organizations better secure software supply chains, he added. NTT Security Corporation previously acquired WhiteHat Security in 2019 to extend the reach of the services it provides. Since then, SaaS platforms for testing application security have become more widely available.

    The acquisition comes at a time when many organizations are trying to determine how far left to shift responsibility for application security toward developers. While developers have a role to play, Schmitt said that shifting responsibility for applications completely left is a fallacy. DevOps teams will need to rely more on platforms that provide guardrails that enable developers to build secure applications in a way that doesn’t create a lot of additional friction, he said.

    Unfortunately, cyberattacks against applications are increasing in complexity and volume. That makes it a challenge for both application developers, DevOps teams and security professionals to keep track of how threats to applications are evolving, said Schmitt. As more companies rely on software to drive digital business initiatives, Schmitt said the business risks those organizations will face are only going to increase. In an era where developers far outnumber security professionals, he added that the only way to rise to that challenge is to rely more on SaaS platforms that enable organizations to implement DevSecOps best practices within their existing application development workflows, he noted.

    Today, the challenge is that much of an organization’s security budget is allocated to networks and endpoints rather than applications, added Schmitt. It’s not clear to what degree that spending needs to shift toward application security or if a larger portion of the application development budget needs to be allocated to security. One way or another, however, it’s apparent that overall spending on application security needs to increase to combat the increasingly frequent attacks.

    In the meantime, the historical divide that has existed between developers and cybersecurity teams should narrow as more security tools are made accessible to developers and DevOps teams alike. Otherwise, security professionals will continue to point out security issues that might affect an application running in a production environment and developers will continue to ignore issues they don’t see as relevant or that they don’t have time to patch. Not surprisingly, most vulnerabilities in applications running in production environments remain unpatched; the only way forward is to rely on automation to eliminate them before the application is ever deployed.

  • MDR for DevSecOps: How Managed Security Can Help You Shift Left

    MDR for DevSecOps: How Managed Security Can Help You Shift Left

    What is managed detection and response (MDR)? Managed detection and response (MDR) is an outsourced service that helps organizations detect threats on endpoints, respond to them and carry out proactive threat hunting.

    MDR services typically include an endpoint detection and response (EDR) platform, which is deployed on company endpoints, and human security experts. MDR providers give their customers access to security analysts and engineers who can help with endpoint security, network security management, triage of alerts and responding to real security incidents (here’s some further reading and more background on managed detection and response platforms).

    Why is MDR Important?

    Traditional managed security services (MSS) offer basic monitoring and alerting that do not provide the context and guidance needed to identify, respond to and remediate real security incidents. It leaves organizations exposed to many threats that pass through these basic services.

    How MDR Helps Protect Organizations

    MDR provides a proactive, outcome-driven approach that goes beyond the scope of what MSS vendors can offer. Common MDR services include:

    • Continuous network and endpoint monitoring.
    • Security orchestration.
    • Threat hunting.
    • Integrated response actions like remote threat containment.
    • Advanced MDR services also offer extended detection across clouds such as AWS, GCP, Azure and common SaaS suites like Google Workspace and Office 365. Other providers can protect incident command systems (ICS) and supervisory control and data acquisition (SCADA) systems within operational technology (OT) environments.

    What is DevSecOps?

    DevSecOps is a software development methodology that unifies previously disparate development (Dev), security (Sec), and operations (Ops) teams. It aims to integrate security across all development life cycle phases, including design, development, testing, deployment and delivery. It involves using automation to integrate security across all phases.

    In the past, security tasks were performed at the end of the development pipeline by a separate security team. Next, the product was tested by a quality assurance (QA) team. This approach worked when developers released software updates only once or twice per year. However, once software development teams adopted Agile and DevOps pipelines to reduce the development time, security became a bottleneck.

    How DevSecOps Improves Security

    DevSecOps integrates security into Agile and DevOps pipelines. It ensures teams can address security issues during the early phases of the development cycle. As a result, teams can apply fixes when it is easier and faster to remediate before products are released to production.

    DevSecOps makes security a responsibility shared by all teams, including Dev, Sec and Ops. It is no longer the sole responsibility of one team that creates a security silo. Instead, it enables teams to automate secure software delivery, prioritizing security without slowing down the software development cycle.

    How Managed Detection and Response (MDR) Solutions Benefit DevSecOps

    DevOps has revolutionized application development. However, due to the high velocity of modern development methods, they can introduce security gaps and flaws.

    In addition to regular security breaches occurring across the DevOps pipeline, new and sophisticated attacks, most significantly supply chain attacks infect the development systems themselves or third-party software components. This results in mega-attacks that can compromise millions of devices before being detected.

    How can MDR help?

    MDR is a relatively new cybersecurity offering but is beginning to have a major impact on companies seeking better protection with lower operational overhead. There are many overalls between MDR and DevOps. To integrate cybersecurity into production and deployment pipelines, some organizations are turning to a DevSecOps approach and MDR can help.

    DevSecOps makes cybersecurity an integral part of the entire DevOps life cycle. As more organizations implement DevSecOps, they can supplement the knowledge and security best practices of in-house teams with the security expertise provided by MDR services.

    How MDR Keeps DevOps Ahead

    MDR keeps DevOps teams ahead of the latest threats by keeping developers up-to-date on emerging threats and vulnerabilities and providing advanced tools for continuous security monitoring and response in their development and deployment pipelines. A key benefit of MDR is that it provides access to experts who can take action to prevent attacks, not just provide recommendations.

    MDR becomes a supporting element that allows developers to write more secure code as well as better secure their DevOps environment. With the help of MDR technology and experts, it becomes easier to identify advanced threats that can bypass security controls before they impact the DevOps environment or the resulting software product.

    Considerations for Selecting an MDR Solution

    • There are several important considerations when choosing an MDR platform suitable for a DevOps environment:
    • Understanding of attack surfaces common in a DevSecOps environment, and the ability to monitor and control the relevant environments.
    • Measures are taken to eliminate false positives and prioritize alerts. DevOps teams operate at high velocity and do not have time to wade through irrelevant alerts.
    • Automated triage and response at all stages of the development lifecycle. In earlier stages, this should take the form of actionable recommendations for developers, and in later stages, full incident response for production environments.

    All of this is useful as you find the right way to shift your organization to a true DevSecOps process.

  • 15 DevSecOps Best Practices

    15 DevSecOps Best Practices

    DevOps is all about speed, agility and collaboration. But when it comes to security, DevOps teams often face unique challenges. From securing the application development process to protecting production environments, DevOps and DevSecOps teams need to be aware of a variety of potential security risks.

    To help you stay ahead of the curve, we’ve compiled a list of 15 DevOps security best practices and challenges.

    1. Secure your application development process

    The first step to securing your DevOps pipeline is to ensure that your application development process is secure. This means ensuring that only authorized developers have access to your code repositories and that all code changes are reviewed and approved by a qualified reviewer before being merged into the main branch. It also helps to have developers that you trust to do the job properly and to observe cybersecurity best practices throughout. Consulting places like rightpeoplegroup.com makes finding these kinds of professionals much more straightforward. 

    2. Protect your production environment

    Your production environment is where your application will ultimately be deployed and used by your customers. As such, it’s important to ensure that this environment is as secure as possible.

    One way to do this is to segment your production environment into separate tiers, each with its own level of access and security controls. This way, even if one tier is compromised, the others will remain protected.

    3. Implement least-privilege principles

    In general, it’s best to follow the principle of least privilege when it comes to granting access to your DevOps resources. This means giving users only the permissions they need to perform their job and no more. The reason this is so important to follow is that your employees constitute your biggest cybersecurity threat. This is not always for nefarious reasons, but often simply because they do not have the knowledge or understanding to keep your business digitally secure at all times.

    4. Use role-based access control (RBAC)

    Role-based access control (RBAC) is a type of access control that can be used to restrict access to DevOps resources based on the roles of users. For example, you could create a ‘developer’ role that has access to your code repositories and a ‘tester’ role that has access to your staging environment. By using RBAC, you can help limit the damage that can be caused by an insider threat.

    5. Encrypt sensitive data

    Any data that could potentially be used to identify or harm an individual should be encrypted, both at rest and in transit. This includes data such as social security numbers, credit card numbers and health information.

    One way to encrypt data is to use pretty good privacy (PGP) encryption. PGP uses a combination of public key and symmetric key cryptography to protect your data.

    6. Use two-factor authentication

    Two-factor authentication (2FA) is an additional layer of security that can be used to protect access to DevOps resources. With 2FA, a user is required to provide two pieces of evidence to verify their identity. The first piece is something they know, such as a password, and the second piece is something they have, such as a mobile phone.

    Implementing 2FA can help to prevent unauthorized access to resources and systems, even if a user’s password is compromised.

    7. Use secrets management tools

    A secret is any piece of sensitive information that should be kept confidential, such as a password or an API key. Secrets management is the process of securely storing and managing secrets.

    There are a number of secrets management tools available, such as Hashicorp’s Vault and AWS Secrets Manager. These tools can help you to centrally manage secrets and provide access control and auditing capabilities.

    8. Train your employees in security awareness

    One of the best ways to improve DevOps security is to train your employees in security awareness. This can help them to understand the importance of security and to identify and mitigate risks.

    There are a number of different security awareness training programs available, such as the SANS Security Awareness Program. Alternatively, you could create your own program tailored to the specific needs of your organization.

    9. Use a web application firewall (WAF)

    A web application firewall (WAF) is a type of firewall that can be used to protect web applications from attack. WAFs work by inspecting incoming traffic and blocking requests that contain malicious payloads.

    There are a number of different WAFs available, both open source and commercial. Some examples of WAFs include mod_security for Apache, NGINX Plus and F5’s BIG-IP ASM.

    10. Perform regular security audits

    Regular security audits are an important part of DevOps security. They can help you to identify weaknesses in your system and ensure that your security controls are effective.

    There are a number of different types of security audits, such as penetration testing and code reviews. It’s important to choose the right type of audit for your needs. If you are unsure, you can consult with a security expert.

    11. Use intrusion detection and prevention systems (IDPS)

    Intrusion detection and prevention systems (IDPS) are designed to detect and block malicious activity. IDPSes can be used to protect both physical and virtual resources.

    There are a number of different IDPSes available, both open source and commercial. Some examples of IDPSes include Snort, Suricata and Bro. They are often deployed as part of a security information and event management (SIEM) system.

    12. Implement a disaster recovery plan

    A disaster recovery plan (DRP) is a document that outlines the steps that should be taken in the event of a disaster, a breach or other security incident. The DRP should contain information such as contact details for key personnel and procedures for restoring systems.

    A DRP can help to minimize the impact of a disaster and ensure that your organization is able to recover in a timely manner.

    13. Use logging and monitoring tools

    Logging and monitoring tools can be used to collect data about the activity on your system. This data can be used to detect and investigate security incidents.

    There are a number of different logging and monitoring tools available, both open source and commercial. Some examples of logging and monitoring tools include Splunk, ELK Stack and Nagios.

    14. Conduct regular penetration tests

    Penetration testing (or pentesting) is a type of security test that simulates an attack on your system. The goal of pentesting is to identify vulnerabilities that could be exploited by an attacker.

    Penetration tests can be conducted internally or externally. External penetration tests are often performed by third-party security firms. Internal penetration tests can be conducted by your own staff or by using a tool such as Metasploit.

    15. Use access control lists

    Access control lists (ACLs) are a type of security measure that can be used to restrict access to DevOps resources. ACLs work by defining a set of rules that determine who is allowed to access what.

    ACLs can be used to implement a least-privilege policy and can help to prevent unauthorized access to sensitive data.

    Conclusion

    There are plenty of threats when it comes to DevOps and DevSecOps and, equally, a wide range of best practices that can be used to improve DevSecOps. By implementing these best practices, you can help to protect your system from attack.

  • Securing APIs at the Speed of DevOps

    Securing APIs at the Speed of DevOps

    In the 2021 State of DevOps Report, 83% of IT decision-makers told Puppet that their organizations were in the process of implementing DevOps practices to improve the quality of their software, the speed of their delivery and the security of their systems. Those DevOps organizations varied in their stages of evolution, however. For example, respondents in the middle stages of their journey reported that culture blockers such as unclear responsibilities and insufficient feedback loops were making it difficult for them to continue their DevOps journeys and join the ranks of high-evolution organizations. Such obstacles help to explain why 97% of high-evolution organizations had already applied automation to their competitive tasks compared to just two-thirds of mid-level and a quarter of low-evolution teams.

    The Importance of APIs to DevOps

    The prevalence of automation ties into the importance of application programming interfaces (APIs) for any organization’s DevOps journey. In the words of IBM, an API “enables companies to open up their applications’ data and functionality to external third-party developers, business partners and internal departments with their companies.” APIs, therefore, enable the services and products of different companies to communicate with one another in a way that streamlines and/or augments functionality for the user.

    That said, users aren’t the only ones who benefit from APIs. DevOps teams do, too. Many of these team members deal with increasingly automated processes as part of their daily tasks, so they need APIs that can help them to deploy and configure their infrastructure. APIs can also help DevOps teams gain detailed information about an app during runtime. DevOps staff can use these insights to proactively address issues before they lead to disruption.

    Security Obstacles of APIs and DevOps

    Despite their benefits, APIs and DevOps aren’t without their security challenges. Contemporary Computer Services, Inc. (CCSI) identified several security hurdles that organizations may encounter along their DevOps journeys. These include the following:

    A fast development process: DevOps introduces a faster speed of software delivery. In their efforts to keep up with this demand, developers might make coding mistakes that leave applications vulnerable to attack. Absent a timely security review, those vulnerable products and services might make it into production, granting attackers an opportunity to exploit the flaws and to try to access affected customers’ digital assets.

    Poor collaboration: No DevOps journey will succeed without collaboration between development and operations. When there’s a lack of joint processes, these teams may stick to their silos. This way of working may leave security gaps if development and operations aren’t communicating about the management of their credentials, tokens, SSH keys and other secrets, for example.

    Those security challenges can then spill over into APIs. The speed of development along with poor team communications may give rise to multiple versions of the same API. This redundancy contributes to a sense of what’s known as API sprawl, a phenomenon where the number and reach of organizations’ APIs grow exponentially. API sprawl comes with its own obstacles including maintenance difficulties and broken clients, issues that provide attackers with more opportunities for infiltrating the organization’s systems. This reality helps to explain why 91% of enterprises experienced an API security incident in 2020 and why malicious API traffic increased by 300% in the middle of 2021.

    How Can Organizations Address These Security Challenges?

    For an answer to this question, we look back to what highly evolved DevOps organizations are doing. Most organizations are focusing on DevSecOps. In Puppet’s report, 51% of respondents said that they are integrating security into their DevOps requirements, with even more saying the same about design (61%) and build (53%). An additional 52% of survey participants indicated that they’re bringing security into their testing. By contrast, mid- and low-evolution organizations mainly engaged in security when they were in the process of preparing for an audit of their production systems or when they learned of an issue affecting production.

    Beyond those areas of focus, organizations need to emphasize runtime protection. Salt Security agrees with this statement, noting how organizations need to “security test your APIs, but know that you will also need runtime protection to catch changes that don’t go through standard build process and abuses that testing tools aren’t designed to find.”

    Finally, organizations need to treat DevSecOps as the cultural change that it is. They can do this by assigning security responsibility to one person from their DevOps team. Doing so will help to ensure that teams won’t overlook security during their jobs. Simultaneously, organizations can conduct security awareness training for their developers and regularly invite both development and operations to share their stories, priorities and successes with one another. This will help to foster collaboration, thereby minimizing instances of API redundancies and API sprawl across their systems.

  • Apple Outage Outrage | Linux Random Redo | Okta Hacked (or Not)

    Apple Outage Outrage | Linux Random Redo | Okta Hacked (or Not)

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Why Apple services were down, Linux gets a huge RNG overhaul, and we wonder if Okta was hacked again. (more…)

  • Secure Software Summit: Behold the SBOM

    Secure Software Summit: Behold the SBOM

    With supply chain security becoming more of a focus, the SBOM is now viewed as a critical element in shoring up supply chain security. SBOM stands for software bill of materials. At a very elementary level, an SBOM is a list of ingredients. Think about how every food product in the supermarket lists ingredients so, for example, people who are allergic to nuts can avoid nuts. An SBOM does the same thing for software applications. 

    If you want to do business with the U.S. government, SBOMs are no longer optional. Executive order 14028 requires an SBOM for all U.S. federal software procurements. Why the push for SBOMs now? Software companies generally do not list all the components included in the software they produce. Knowing what components are included in applications is essential for proactive vulnerability management. That said, the government mandate for SBOMs only requires a minimal amount of included information—supplier name, the component name and version, dependency relationships, time stamps for versions or modification and information about who authored the SBOM itself. 

    What to Look For in an SBOM

    This minimum required data yields minimal benefit for cybersecurity risk reduction and vulnerability management. SBOMs can actually include many other types of information. What information should you include in SBOMs for software applications produced, purchased or consumed by your organization? Here is a list. 

    Authenticity —Authenticity asks and verifies that someone actually created a listed component. Ideally, this requires a digital signature of some sort. Authenticity can be particularly important in the case of nested components where the supplier of an application includes multiple other components, as is common with JavaScript and Java libraries used for common functionalities. 

    Integrity —This addresses whether a component has been tampered with or modified without authorization. An SBOM should include some measure of integrity. Equally important is proving the integrity of the SBOM itself. Just as CheckSum can tell you whether software you are loading matches what the source of that software indicates, integrity checks should allow you to verify that components on an SBOM (and the SBOM itself) are exactly what you are expecting. 

    Services —An inventory of services called by an application is critical. Modern software does not live in a vacuum. It calls out to the Internet to perform all sorts of tasks and communication with other systems. Those services that extend beyond your application are part of the inventory because they can be an indication of vulnerability or indicate a larger problem.

    Vulnerability Remediation Status —Development teams are constantly balancing the need to remediate vulnerabilities against the risk that remediation will break the application. Some open source projects, for example, have a history of not backporting security fixes. The latest version of the project may break applications. Organizations are forced to choose between breaking an application or taking the risk of introducing a high-severity vulnerability that might be exploited. Responsible organizations that opt to keep the older version and not break their software will backport their own fixes. An SBOM should describe these variations and any other vulnerability remediation activity. 

    Inventory of component security advisories —An SBOM should describe security advisories pending against all components. This is likely to be a dynamic list that you will need to automatically update using one of the accepted vulnerability advisory formats (CSAF and CycloneDX, to name two). In fact, this is one of the strengths of SBOMs—they are designed for automation and to act programmatically. 

    Completeness —It is not always possible to ship complete SBOMs, either for technical or intellectual property reasons. An SBOM should indicate whether it is complete and whether it contains a comprehensive inventory of dependencies and services. 

    Pedigree —This information describes the DNA of the SBOM and the original makeup and changelog of each particular component. An SBOM should describe the original component, exactly what changes were made, who committed the changes and why, what the differences were between different versions and what security issues were fixed with each variation and version. 

    Provenance —This relates to the origin of a component or service. It can describe a repository that the component was downloaded from, a country of origin, the name of a software manufacturer or open source project or other information indicating the component or service’s source of origin. 

    License type —License information is relevant for compliance and to ensure that your organization is not consuming or producing software in a manner that violates licensing terms. Moreso than for security and vulnerability, this information is for risk management, compliance enforcement and auditing. 

    Customizing SBOMs to Meet Your Needs

    The SBOM is a flexible and highly adaptable approach that can be easily customized to fit specific use cases. You can design SBOMs to meet the specific needs of your use case, either as a software provider or consumer. You also may need to modify your SBOM fields and data design as your needs evolve. Fortunately, it is rapidly becoming easier to automatically generate SBOMs using software security tools such as software composition analysis (SCA) and interactive application security testing (IAST) solutions. SBOMs can also be created or read automatically at other points during the build life cycle along the continuous integration/continuous deployment (CI/CD) process. Just as you would not buy a box of cereal that did not list the ingredients, in the future you will not want to consume software that does not have a detailed SBOM. What you don’t know about the software you run can hurt you, and SBOMs will be a crucial tool in providing greater transparency and observability into the software supply chain. 

    About Secure Software Summit
    The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.

    https://go.shiftleft.io/secure-software-summit-2022-replay

  • Secure Software Summit: Reachability and Risk for Security Leaders

    Secure Software Summit: Reachability and Risk for Security Leaders

    It is impossible to manage security posture without considering two key factors in any potential vulnerability or security flaw: Reachability and risk. The two factors are related. Reachability defines the degree to which a given security vulnerability that is detected, such as a CVE, can actually be attacked and exploited to gain privileged access and directly or indirectly access critical systems or data. Risk is a business measurement that assesses the potential for a vulnerability to actually damage an enterprise or organization. In general, without reachability, there is less risk. 

    How to Think About Reachability

    Reachability and risk have dramatically shifted in recent years as we have moved from a hard perimeter “fortress” approach to security to more distributed systems, APIs, cloud computing, SaaS and far more potential points for attack ingress and exfiltration egress. To mitigate this new risk landscape, we have actually moved to fortify all the newly exposed internal elements and the critical systems of security. We have built a new perimeter around identity, with authentication and zero-trust. We have built perimeters around connected devices, around our cloud infrastructure and our virtualized environments and our configuration of all these systems. At every point where there is a potential for risk, you need to think about fortifying the new mini-perimeters. 

    A key aspect of risk and reachability that we have spent less effort on is the human aspect. We do not yet consider people as a perimeter to be defended, even though people comprise the most reachable vulnerability. As people, we create flawed software. We misconfigure our infrastructure, our security tools and our authentication systems. A key part of the new mindset of reachability must be better accounting for and mitigating the risks of people. This means simplifying their decision trees, either through better systems or better design, and by helping them become a better gray-matter perimeter. 

    Due to the atomization of our IT and application environment, and the resulting miniaturization of our security fortresses, we have created a far more granular surface. In some cases, such as through segmentation, we have enhanced security and reduced risk; in other cases, we have added complexity. Without a doubt, we now have many more points of contact and a broader attack surface exposed to the world. A critical consideration when assessing reachability is how far each of those points can be exploited, and to what breadth and depth—looking at horizontal traversal and immediate compromise of critical systems or subverting supply chain and other pivotal subsystems for subsequent attacks. The miniature fortress mentality is a useful framework for thinking through the potential attack surface and putting in place the right controls, at the right places, to address reachability.

    Risk Scoring and Reachability

    So what is the interplay between risk scoring and reachability? We cannot say no to new technologies that introduce more complexity, and potentially more risk, if our end users are demanding them. We need to better manage how risk scores are created and applied to help people perform better in this environment of greater complexity. 

    Today, the responsibility for understanding the complete security picture and applying the proper context to decision-making and judgments has grown more widespread. Everyone who is deploying, using, building or designing applications and technology environments must be constantly thinking about the security implications of whatever project or code they are working on. The lens for those implications is not only at the application or system or infrastructure level but for the general well-being of the business. This means a broader understanding of risk scoring driven by reachability and criticality and taking into better account the implications of reachability and attackability. 

    In cybersecurity, there is no shortage of risk measurements. Injecting reachability into the scoring process is a way of framing vulnerabilities to prioritize which of these issues are likely to be an actual risk. It is possible to have something that comprises a major business risk but have a very low reachability context, which may lead a security team to treat that vulnerability differently. 

    Broadly speaking, however, it is insufficient to make decisions solely based on programmatically generated risk scores. Any risk score is a reflection of the system generating the score, and how that system was tuned, either by the vendor or by your team. It is important to always remember that any risk score involves some subjective judgments. This is necessary, but injects opportunities for drift and bias that may skew scores in ways that leave you less secure.

    To be clear, risk scores serve a crucial purpose in application security. Risk scores help you reduce the noise and find signals amidst the flood of CVEs and vulnerabilities and alerts. In fact, there is today so much noise around security that any effective team relies on multiple layers of noise reduction in their decision chain and prioritization and policy efforts. Where risk scores fail is with the inability to map accurately to business risk or by inaccurately reflecting the reachability of any CVE or other reported issue. This requires security teams to build their own internal and mental models of risk, modeling threats against the most critical systems and creating context that can be used to verify decisions by the risk scoring systems. Knowing how data flows through applications and infrastructure is crucial if a human agent can quickly judge the reachability and attackability of any given vulnerability presented or recognize when the automated risk scoring engines may not accurately reflect business risks. 

    In effect, there are two different processes at work: Calculating risk and contemplating risk. Calculating risk is programmatic and automated; human-guided, initially, but driven by models applied against the mass of vulnerabilities surfaced by security testing tools like software composition analysis, static application security testing, fuzzing and linting. Contemplating risk is a more holistic exercise that leverages the human capacity for intuition and innate knowledge of systems driven by experience and hard-won insights. 

    Contemplation is what will help security teams identify undetected biases, guide threat modeling to better consider drift and highlight areas where human breakdowns might have augmented risk in ways that a risk scoring system could never capture. Above all, contemplation is about context. The more context a human actor has, the better they can understand the big picture. The greater the understanding of the big picture, the better decisions people make. This must also flow through and inform the models and the risk scoring engines so that the value of contemplation is captured in the calculation. 

    Using Risk Scoring Tools to Minimize Reachability and Attackability

    A security team must constantly measure the efficiency and efficacy of all security tooling. The general rule is that security controls lose efficacy over time as vendors lose focus or fail to account properly for emerging classes of threats. When you have a security tool that generates risk scores in tune with your reachability guidelines and proves accurate, you should elevate that system to a higher level of trust and give more weight to its findings. That said, even tools that generate risks you think are accurate and perform well must be constantly evaluated and cross-checked. 

    Unfortunately, it only takes a small amount of drift to open up an organization to potentially catastrophic attacks. A critical part of this calculation is ensuring that humans stay on top of how the risk scores are created and continue to influence the scores to fight drift. Drift is natural but it is not inevitable. Your code and environment are constantly changing, This may result in changes in reachability which can materially impact your overall risk posture and should alter the way you approach different systems and risks. An automated risk scoring system may not understand that a new type of supply chain attack might result in subsequent related attacks on similar components in other operating systems, to name one example. Human intelligence and contemplation, really, is the secret ingredient that makes risk scoring tools far more valuable and reliable.

    Takeaways: Atomized Systems, Reachability and Risk and Humans

    The environment and application landscape will continue to atomize further as we move into new infrastructure paradigms like edge computing and all systems on the network gain capacity. For this landscape, security teams and the developers they work with on shifting left should:

    • Recognize that we have shifted from a global perimeter to an atomized constellation of mini-perimeters and shift their mindset to consider security and building fortresses at the micro level as a key way to reduce reachability and risk
    • Developers and security teams need to assess the systems they build and protect on the basis of reachability and risk to properly prioritize. Risk scoring tools are useful elements for reducing noise but cannot supplant human intelligence to gut-check risk decisions
    • All along the way, humans have to continue to guide and inform these risk scoring systems and ensure that risk scores do not become blind proxies for criticality and importance. Allowing automated risk scoring to dominate the decision process can make security drift more dangerous and allow human error to go unrecognized, leaving applications and infrastructure both reachable and at risk.

    This article was co-authored by Bryan Smith, CTO, RiskLens and Rob Lundy, director of product marketing, ShiftLeft.

    About Secure Software Summit
    The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.

    https://go.shiftleft.io/secure-software-summit-2022-replay

  • Secure Software Summit: Applying Chaos Engineering to Software Security

    Secure Software Summit: Applying Chaos Engineering to Software Security

    Today’s software systems are, essentially, controlled chaos—and lightly controlled chaos, at that. This makes it exceptionally challenging to model the behavior of those systems. Our systems are quickly becoming larger and larger, with more and more moving parts. It is not uncommon for enterprises to have over 1,000 microservices and millions of containers running thousands of applications containing many thousands of open source libraries. 

    Why are things growing more complex? Because from microservices to CI/CD pipelines, from service meshes to blue/green deployments, all these new practices and new technologies help us make our applications and infrastructure more resilient and scalable. The downside is the ever-increasing complexity, which is actually accelerating. 

    In addition, software has officially taken over every layer of the networking and hardware stack (which sounds like an oxymoron, but it’s containers and virtualization turtles all the way down until you hit bare metal). Software is, by definition, easy to rewrite. Thus, the ease of changing software has further increased the number of changes we make to systems. Which adds still more complexity. In fact, software only ever increases in complexity; never decreases in complexity. Software is always trying to do more and encompass more. For that reason, even when you try to simplify software, you just move the complexity around rather than eliminating it. 

    Introducing Turbulence

    Here is how Netflix, the organization that pioneered chaos engineering, defines the practice: “Chaos engineering is the discipline of experimenting on a distributed system to build confidence in the system’s ability to withstand turbulent conditions.” Turbulence is the opposite of order, but it’s where all systems end up.

    In the beginning of a system’s life cycle, there is always an orderly plan for deployment and operations. You always have a clean diagram of your resources, code repositories, containers and always a nice 3D diagram of AWS instances you will deploy to and the network topology. 

    In reality, our systems are never this simple. After the system goes live, that is when we start learning about how it actually operates through unforeseen events like when marketing asks to refactor the pricing module or an outage to the payments API forces you to hardcode a token or a DNS outage—well, you know about DNS outages. In the span of a year or two, you go from 300 to 800 microservices and you have to add Kubernetes clusters and a container network interface (CNI) to properly secure the networking of those clusters. And so on and so on. The bottom line? Almost all production systems evolve into a state that we do not understand and cannot easily map back to our original systems diagram. 

    Chaos engineering is a mechanism for dealing with this growing level of complexity. The basic idea behind chaos engineering is asking the computer or application or network (or any other environmental element) a series of questions. Consider a legacy system like a mainframe. How did our legacy systems become so stable? They are well-documented. Engineers feel confident in how the system operates. The question is, was the system always that way? Is the system the same one that they originally designed? The answer is “No.” 

    Legacy systems actually went through a trial-by-fire; a constant parade of unforeseen surprises. These surprises were, effectively, questions. Through these surprises, engineers learned how the system would actually operate (or wouldn’t operate) in the face of chaotic and unforeseen events. This process created iterative feedback that helped the engineers learn how to make the system continuously more stable. 

    The point of chaos engineering is to generate this same type of feedback loop without the pain, stress and repercussions of unforeseen (and generally unwanted) events. Thus, chaos engineering is a proactive way of introducing adverse conditions to ensure that the system can still do what it’s supposed to do when unforeseen events transpire. Because everything today is software and change is constant, the questioning must also be constant. 

    For example, chances are that in the time since we originally designed any given system, it has changed a lot. This means some or all the mitigation and resilience we programmed in—retry logic, failovers, circuit breakers—are old news, designed for an older system. When triggers for those conditions actually occur, those mechanisms of resilience we designed may not perform as we had intended.  

    Chaos engineers proactively ask the question, “Under the conditions in which you are designed to perform, do you do what you are supposed to?” We introduce the conditions themselves in a controlled manner with a limited blast radius to put the system to the test and verify that our assumptions line up with the intended reality. The practice of chaos engineering is intended to be performed on live, running systems without the risk of taking down critical production assets or ambushing unsuspecting applications and their associated DevOps and development teams. This helps engineering teams reduce uncertainty by building confidence in their understanding of their systems by providing them with enhanced context. It turns out that, when engineers are presented with better context, it considerably improves their ability to make smarter, well-informed decisions where resilience is concerned. 

    Chaos Engineering for Cybersecurity

    Cybersecurity is a context-dependent discipline, dependent on how well you understand the systems you are protecting.  Software engineers are constantly changing the system. And they must have the flexibility to change it because their primary task is to constantly move towards business value. Yet to effectively apply cybersecurity practices, we must know what we are trying to secure. From that knowledge, we then can know what we most need to secure and how to do it on a given system in its most current state. 

    Before an engineer can understand how to build robust security measures that provide effective cybersecurity, the engineer must first understand the system. This reliance on the “system first” is a foundational driver for why our security systems and controls—even the immutable and ephemeral ones—experience considerable engineering drift over time. We are continuously burdened by the dependence on a stateful understanding of the system.  

    Without having some sort of testing or instrumentation feedback loop in our post-deployment world, we don’t know there is a problem with our security until there is an actual problem. Finding out that the room is on fire after the house has been burning for hours is too late. The result is the self-defeating series of reactive incident fire drills, war rooms and outages that we find ourselves in today. If we do not change this reactive crisis loop of chasing the tiger’s tail, it inevitably leaves us taking two steps back for every step we take forward with engineering teams. 

    When this drift goes undetected, we are left with our wounds exposed and attackers salivating at the meal to come.  Engineers always prefer to find evidence and sources of drift through some internal engineering failure or controlled test rather than experiencing a successful real-world attack. Over time, there is a constant drift between the system and security; engineers are constantly changing the system. As a result, there is frequently a lack of recalibration between systems and the security designed to protect them. The way to achieve this recalibration is through continuous testing or experimentation. 

    Testing is not chaos engineering. Testing is a verification and validation of something you know as either true or false. This could be vulnerability to a specific CVE or exposure to an attack pattern. In experimentation, you are trying to derive new information and explore the unknown unknowns. From this exploration, you seek to create a  better understanding of how a system reacts and then share that with the people who are designing the system.

    Live security incidents are not effective measures of detection because, by then, it is already too late in the life cycle to effectively address the problem. Worse, incidents cause stress, fear and irrational behaviors. People freak out. Not surprisingly, a security incident is not a good learning environment. Yet security incidents serve the same purpose: Asking questions about a system or systems and helping teams see how to improve them. Chaos engineering offers a better way to create these questions under conditions where it is easier to learn and observe system behaviors, providing clues to improving security. In other words, the purpose of security chaos engineering is to help us proactively understand our systems and where the security gaps are before an adversary has a chance to take advantage of them.

    There are multiple use cases for security chaos engineering including:

    • Incident response: Testing efficacy of run books, response plans, and determining whether data collection and alerting systems work as intended
    • Security control validation: Introducing conditions that should induce behavior from one or more controls and observing behavior
    • Security observability: Introducing unexpected attacks or breaches to see if your systems report and observe the incident accurately
    • Compliance monitoring: Applicable across all chaos engineering events by documenting that systems do what they say they are supposed to do

    A Practical Example

    A team I headed wrote an open source application, ChaoSlingr, designed to generate chaos engineering events for security experiments. The application consisted of three serverless functions to generate the experiment, apply it to infrastructure and then monitor the resulting impact on the system. 

    One example of how we used ChaoSlingr was an exercise where we induced an open port. Enterprises and engineers inadvertently open ports in firewalls all the time. Sometimes this is a result of misconfiguration. It may also be the result of a software upgrade after which the developer or AppSec engineer forgot to reset the port to the proper security settings. In theory, firewalls should automatically detect an unauthorized open port.

    For the experiment, we selected a set of resources that had opted-in to our experiments, selected a security group and opened the port. At the time we were relatively new to Amazon Web Services. We were surprised to find that the firewall only detected an unauthorized port opening 60% of the time. We discovered clear evidence of configuration and security tool drift. 

    We also noticed that a cloud-native configuration and management tool we had deployed was identifying and alerting the unauthorized port opening almost 100% of the time. We then realized that correlating and responding to incident events of an unauthorized port opening was complicated; it was hard to map the incident back to the log data describing how our systems responded to the event. We added a metadata pointer to each alert, allowing us to more easily correlate the information and save valuable time finding the affected security group and port. 

    In short, the exercise gave us excellent context on where our systems were drifting and failing to keep up, which of our systems were the most reliable and whether we could quickly and easily respond to these incidents by chasing down the right log files. 

    Security Chaos Engineering Programs Build Trust

    In any environment where we are managing complex systems, trust is critical. You must trust that your systems will handle unforeseen events gracefully and not cost your company money or reputational currency. You must trust that the people designing and building your systems are constantly trying to improve them.  You must trust that the security teams protecting your systems are up to the task. As systems grow more and more complex, the number of unknown unknowns multiplies. As humans, with our limited processing capacity, we cannot solve for unknown unknowns at scale, continuously. This is the task of security chaos engineering and the processes around it: To create a programmatic way to experiment against and find answers to unknown unknowns. Your systems, developers, customers and your CEO will thank you for it.

    About Secure Software Summit
    The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.

    https://go.shiftleft.io/secure-software-summit-2022-replay