SecureStack Community Edition Is Free!

SecureStack Community Edition Is Free!

One of the unique things about SecureStack is that its used by people who come from different backgrounds and roles, not just developers.  Sure, we have a lot of users who are software engineers, but we also have security researchers, appsec teams, SOC analysts, CISO’s, pentesters and bug bounty kids using our platform.

We want to encourage this dynamic community, so we are excited to announce that as of June 1, 2023 we will offer a completely free version of our platform.  We call this “SecureStack Community Edition” because that’s exactly who this was designed for:  our community.  It will come with 20 monthly analyses, and support all of our scanning technologies:  web, cloud, code and secrets.

You can sign up for a free account here: https://app.securestack.com/auth/register

complete-security-coverage-startups

Complete security coverage across the whole SDLC

The SecureStack platform offers an integrated suite of security tools that work together and all report to the same dashboard.  One unified view and one subscription to pay.  Easy.

 

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 

Software Supply Chain Security

Software Supply Chain Security

Software supply chain attacks have grown exponentially over the last three years:  malicious packages, package manager corruption, continuous delivery pipeline attacks, dependency confusion, zero days in open-source software and more.  This is driving many organizations to look for better visibility across their software supply chain. 

Let’s dive in a bit to see why the problem is growing and some potential solutions.

Application complexity is increasing

The reality is that modern applications are complex and dynamic, and therefore hard to secure. They use programming languages that run entirely in the browser, they talk directly to their dependencies on the internet and they use technologies like containers, serverless and public cloud. All of these bring their own challenges, so we need visibility into all these other application components and dependencies as well. What third-party APIs and public cloud components is it using? Is it using an identity provider like Auth0 or Cognito? What infrastructure is required to make the app run? All of these things need to be understood to really be able to better represent what is in an application and how to secure it.

SBOMs can help address software supply chain risks

One way to address the risks inherent to the complex applications we are building is to use “Software Bill of Materials” also known simply as “SBOM”.  At its simplest, a SBOM is a list of all the different component parts of an application. This typically includes several types of information about each component: Its name, who supplied the component, what license it uses, the version number, any known vulnerabilities, and a list of all the component’s dependencies.

Most SBOM tools that exist right now, focus on showing customers some of the open-source libraries that they are using in their applications.  Moreover, most SBOMs are stand-alone JSON documents and by themselves don’t provide much value.  Even worse, many SBOMs are created once and then never updated so they quickly become out of sync with the actual application they are supposed to describe.

sbom-lifecycle-arrow

What’s in the SBOM lifecycle?

Most SBOM advocates believe that SBOMs should be automatically created during deployment, and should be as descriptive of the actual application as possible.  To do this, organizations need to have a process that identifies applications, creates SBOMs and then makes them available for the business to gain value from.  We believe the best way to do that is to create a SBOM lifecycle policy.

There are five stages in the SBOM lifecycle: Asset discovery, application data analysis, SBOM creation, SBOM storage and SBOM searchability.

Let’s go through each of these stages one at a time.

Asset discovery

You can’t onboard what you don’t know about. This stage is all about helping the customer find the applications they need to ultimately provide an SBOM for, which hopefully, is all of them.  Most companies only know about 50% of their public-facing application names.  The other 50%?  Well, that’s the problem. Finding assets with domain names like app.niftybank.org and api.niftybank.org seem obvious but how do you find the less obvious apps? 

asset-discovery

Existing asset discovery or attack surface mapping tools can help find assets but what do you do with the list that these tools have generated?  Most of those tools don’t have any SBOM functionality, so how do you get the list of assets into your SBOM creation pipeline?  It’s better if your solution can find your assets, show them to you and allow them to create a SBOM from that same workflow.

Application data analysis

In this stage, the data that is needed to create an SBOM is collected about the target application. Historically, SBOMs got this info from package manifest files, but now, that’s typically not enough.  Modern SBOMs are able to incorporate data from cloud providers, third-party services and SaaS solutions in addition to source code.

SBOM creation

In this stage, the actual SBOM file is created and will include all the relevant application data.  Typically, you will want this to happen every time your engineering teams deploy a new version of the application.  After all, if you aren’t building a SBOM every time you deploy a new version, is your SBOM going to match the state of your production app?  The only thing worse than no SBOM, is a *wrong* SBOM.

sbom-data-analysis

SBOM storage

SBOMs need to be stored somewhere centrally and protected with a rich authorization layer.  This centralized storage can be an S3 bucket or other secure managed file server, but make sure that they’re stored in an encrypted manner! Otherwise, you might run afoul of compliance requirements!

sbom-cloud-storage

SBOM searchability

Finally, customers need to be able to search across some or all of their SBOMs. Ultimately, all the steps before this one led to enabling this functionality.  This searchability is the most important aspect of the SBOM process because this is the central source of truth. This is how you look up vulnerable software in your environment and find which applications to tackle.

search-sbom

Imagine if you had this functionality back in December 2021 when the Log4j zero-day dropped!  Wouldn’t it have been nice to go to a central place you could go and say “hey, tell me all the places that Log4j is being used and what versions they are!”

Tying it all together

Building a complete SBOM lifecycle can be a challenge, but in the end, the value that it provides to organizations is enormous.  Simply having the ability to quickly find all the software and application components in your estate of apps is huge.   But even better, being able to query that data for vulnerable components could save organizations millions of dollars in lost productivity.  

comprehensive-sbom-securestack

Native SBOM lifecycle

You can build your own SBOM lifecycle or alternatively, SecureStack automates the whole process from end to end.  Our platform delivers all stages of the SBOM lifecycle in a fully integrated solution that is incredibly easy to onboard. Our platform provides an end-to-end SBOM solution that helps organizations address software supply chain risks holistically.  We find all your application assets, automate the creation of your SBOMs, store them for you in a secure central repository, and make them searchable.

Our role-based access control means you can give your security and engineering teams access to those pieces of the SBOM lifecycle that they need.

 

 

 

See how it works!

If you like what you see, book a demo!

 

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 

New FDA Requirements for Cybersecurity

New FDA Requirements for Cybersecurity

The FDA has released new cybersecurity regulations for medical device suppliers

The Food and Drug Administration (FDA) has announced that medical devices must now meet specific cybersecurity guidelines. Cyber-attacks against healthcare organizations increased by 74% last year, and attacks on the software supply chain have increased an average of 610% per year since 2020.

The federal government has been worried about the lack of cybersecurity maturity in the healthcare industry, especially with so many medical devices being connected to the internet.  The fear is these insecure devices would lead to increased attacks and this set of regulations is part of a coordinated strategy to address these increased risks.

These new security requirements were introduced as part of a $1.7 trillion federal omnibus spending bill signed by President Joe Biden in December. The FDA must update its medical device cybersecurity guidance every two years.

What’s in the new requirements?

Device manufacturers must now submit plans to monitor, identify, and address post-market cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosures and plans, within a reasonable timeframe.  Suppliers must also make security updates and patches available on a regular schedule and in critical situations

The requirement for vulnerability disclosure is in line with what we are seeing from NIST, CIS and other standards organizations.  Unfortunately, many medical device suppliers do NOT currently have vulnerability disclosure programs.

Software engineers must design and maintain procedures to demonstrate, with reasonable assurance, that the device and related systems are secure.  This is commonly referred to as “secure by design” and includes embedding security scanners and other technologies into the day-to-day engineering processes.  Engineering teams must also create updates and patches for the device and connected systems that address known vulnerabilities on a reasonably justified regular cycle.

If issues are discovered outside the software development process, the manufacturer must publicly disclose critical vulnerabilities that could cause uncontrolled risks as soon as possible.

devsecops-playbook-infinity-loop

If you want to learn more about DevSecOps and how it can help your teams embed security into the software development processes you can check out our blog post.

medical-device-sbom-banner

Medical device suppliers must also include a software bill of materials (SBOM) containing all commercial, open-source, and off-the-shelf software components while complying with other FDA requirements “to demonstrate reasonable assurance that the device and related systems are cyber secure.”

SBOMs need to be up-to-date, accurate and validated by a third party.  If you want to learn more about medical device SBOMs, you can check out our blog post on the subject.

So, how do can you address these new requirements?

Medical device suppliers who are building custom software and/or firmware will need to implement several technologies to address the new FDA requirements.  Let’s go through each of these one at a time:

  • Asset discovery & management – The first place to start is with a asset discovery and management solution that will give you insight into what you have and is it internet connected.
  • Application security analysis – Once you know what your assets are you need to make sure that the software you are building is secure.  Software composition (SCA) tools are a great place to start as they help you understand what open-source libraries are in your applications.
  • Vulnerability management – Next up is implementing a vulnerability management platform that will find all vulnerabilities in your hardware and software and prioritize them for you.  This helps you prioritize what to focus on and what’s not really a problem.
  • SBOM – The final part to addressing the FDA’s requirements is implementing an automated third-party SBOM program.  This can be added to your software development automation so that everytime a new release is built for your medical device its been tested and a SBOM has been created.
complete-security-coverage-startups

Complete security coverage across the whole SDLC

The SecureStack platform offers an integrated suite of security tools that work together and all report to the same dashboard.  One unified view and one subscription to pay.  Easy.

If you like what you see, book a demo!

 

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!

 

Medical Device Software Bill of Materials

Medical Device Software Bill of Materials

Cyber attacks on medical devices are increasing

Cyber-attacks against healthcare organizations increased by 74% last year, and attacks on the software supply chain have increased an average of 610% per year since 2020.  These attacks can take various forms that attack the functionality and reliability of medical devices and the software that runs on these devices. This in turn, unfortunately, can lead to mistrust of the device and its manufacturer and ongoing brand damage.

Most medical devices have software running on them and often connect to software on computers, smartphones or mobile apps to share and exchange data.  Having multiple software components in these different places adds security challenges that many medical device suppliers aren’t properly prepared to address.  This is one of the reasons that the US Department of Health and Human Services (HHS) and the Food and Drug Administration (FDA) have partnered to create new regulations for medical device suppliers.

Traditionally, manufacturers of medical devices have not had visibility into what went into the software and firmware running on their devices.  This has led many organizations to try and find better ways for them, and their users, to find confidence in the security of medical equipment.

Government creates rules to address attacks

According to new government requirements, all medical device suppliers must submit a plan to monitor, identify, and address cybersecurity issues. They must also create a process that provides reasonable assurance that their device is protected. Additionally, applicants must make security updates and patches available on a regular schedule and in critical situations. Finally, they must provide the FDA with a software bill of materials, including any open-source or other software components their devices use.

SBOMs can help address software supply chain risks in medical devices

One way that medical device manufacturers can improve visibility is by implementing a Software Bill of Materials, also known as an SBOM.  An SBOM is a comprehensive list of all the software components running on a medical device.  This includes:

  • Open-source and third-party software components
  • Firmware and binaries
  • Cloud resources
  • APIs the device interacts with, or sends data to

The implementation of SBOMs is especially crucial for the medical device industry. Due to the potential risks of medical device software vulnerabilities, regulatory bodies such as the FDA, have made SBOMs mandatory for medical device manufacturers.

With an SBOM in place, manufacturers can identify vulnerabilities and take action to address them before they can be exploited by attackers. This can help reduce the risk of harm to patients and ensure that medical devices are safe and reliable.

Government and industry requirements for SBOM

  • US Federal Government:  On December 29, 2022, the White House signed H.R. 2617, the Consolidated Appropriations Act 2023, which included several cybersecurity provisions.  This bill introduces new requirements for medical device manufacturers to ensure that their devices meet certain minimum cybersecurity standards. These requirements will take effect 90 days after the bill is enacted and include:
    • This involves monitoring, identifying, and addressing cybersecurity vulnerabilities and exploits that arise after a product has been released to the market. This includes coordinated vulnerability disclosure, as well as requiring the release of software and firmware updates and patches to address these vulnerabilities.
    • It also requires medical device manufacturers to provide a Software Bill of Materials (SBOM) to the FDA Secretary, which includes all off-the-shelf, open-source, and critical components used by the devices.
  • FDA:  The Food and Drug Administration (FDA) has published the “Cybersecurity in Medical Devices” guidance document.  You can find all of the FDA’s guidance on cybersecurity here.
  • IMDRF:  The International Medical Device Regulators Forum has published two documents about SBOM.  The first is the “Principles and Practices for Medical Device Cybersecurity” and the second is the “Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity“.
  • US Department of Health and Human Services:  HHS has published the “Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients (HICP)” document.
  • Australian Department of Health and Aged Care:  The Australian TGA has released the “Medical Device Cyber Security Guidance for Industry” document.

How do medical device suppliers get started with SBOM?

All federal agencies mentioned above believe that SBOMs should be automatically created during the software development process.  Moreover, these SBOMs should be as descriptive of the actual application running on, or connected to, the medical device it supports.  To do this, organizations need to have a process that identifies the different steps involved in software development, creates the SBOM and then makes them available for the business to gain value from.  We believe the best way to do that is to create a SBOM lifecycle policy.

There are five stages in the SBOM lifecycle: Asset discovery, application data analysis, SBOM creation, SBOM storage and SBOM searchability.

Let’s go through each of these stages one at a time.

sbom-lifecycle-arrow

Asset discovery

Medical device suppliers typically are building multiple software components for their customers:

  • Firmware and binaries
  • Client applications that run on a customer’s computer
  • APIs to send medical data to
  • Mobile applications that run on smartphones

The SBOMs you create need to cover all 4 of these potential use cases, but most of the SBOM tools out there do NOT.

medical-devices

Application data analysis

In this stage, the data that is needed to create an SBOM is collected about the target device, its firmware and client applications. Historically, SBOMs got this info from package manifest files, but now, that’s typically not enough.  Modern SBOMs are able to incorporate data from cloud providers, third-party services and SaaS solutions in addition to source code.

medical-device-sbom-components

SBOM creation, attestation & signature

In this stage, the actual SBOM file is created and will include all the relevant application data.  Typically, you will want this to happen every time your engineering teams deploy a new version of the application.  After all, if you aren’t building a SBOM every time you deploy a new version, is your SBOM going to match the state of your production app? 

Finally, and most importantly these SBOMs need to be signed by a third party to attest to their validity.

medical-device-sbom-banner

SBOM storage

SBOMs need to be stored somewhere centrally and protected with a rich authorization layer.  This centralized storage can be an S3 bucket or other secure managed file server, but make sure that they’re stored in an encrypted manner! Otherwise, you might run afoul of compliance requirements!

sbom-cloud-storage

SBOM searchability

Finally, customers need to be able to search across some or all of their SBOMs. Ultimately, all the steps before this one led to enabling this functionality.  This searchability is the most important aspect of the SBOM process because this is the central source of truth. This is how you look up vulnerable software in your environment and find which applications to tackle.

search-sbom

Many SBOM tools don’t support medical device SBOMs

Most SBOM tools that exist right now, focus on showing customers some of the open-source libraries that they are using in their applications.  Moreover, most SBOMs are stand-alone JSON documents and by themselves don’t provide much value.  Even worse, many SBOMs are created once and then never updated so they quickly become out of sync with the actual device and applications they are supposed to describe.  Medical device manufacturers need to make sure their SBOMs are up-to-date and accurate.

comprehensive-sbom-securestack

Automate SBOMs for medical devices and client applications!

SecureStack automates the whole process of collecting data and building SBOMs from beginning to end.  We sign and attest our SBOMs so you can provide our reports and data to the government, partners, auditors, or anyone else you choose to.  Our platform delivers all stages of the SBOM lifecycle in a fully integrated solution that is incredibly easy to onboard.  We find all your application assets, automate the creation of your SBOMs, store them for you in a secure central repository, and make them searchable.

 

 

 

See how it works!

If you like what you see, book a demo!

 

Paul McCarty

Founder of SecureStack

DevSecOps evangelist, entrepreneur, father of 3 and snowboarder

Forbes Top 20 Cyber Startups to Watch in 2021!