ISC2 Secure Software Development

ISC2 Spotlight: Secure Software Development conference - day two

Jonathan

• 4 min read
"ISC2 Spotlight" written in white on a green background, with "secure software development" in blue on a white background.

Yesterday's conference sessions were interesting (you can read about them here), and today is the last day of the conference.  Today's agenda:

  • Secure by Design: CISA's Plan to Foster Tech Ecosystem Security
  • SigStore to Secure the Code Supply Chain
  • What You Need to Know About the EU Cyber Resilience Act

Secure by Design: CISA's Plan to Foster Tech Ecosystem Security

CISA is the US Cybersecurity & Infrastructure Security Agency, and our speaker shared their thoughts on how to increase security across all industries with some practical advice.  He started by explaining that when there's a vulnerability found, the vendor should investigate how the vulnerability came to exist by looking at the whole lifecycle.  Obviously it's important to consider the development stage, but it's also important to consider other aspects such as the human factor.  Was the vulnerability introduced because people were too busy?  Perhaps conflicting deadlines played a part?  The goal is to learn from the investigation.

Companies also need to take ownership of the problem and the associated security outcomes.  They can do this by sharing their findings and being transparent about their security programmes.  Some companies publish metrics that relate to their security, for example their Multi Factor Authentication (MFA) adoption.  Security also needs to be implemented with support from everyone in the organisation, from the CEO down.

It was also suggested that companies should have a published vulnerability disclosure policy (which having just reviewed our policies for ISO 27001:2022, I can share is also a requirement for 27001 too).

Products should be designed with security in mind to help remove whole classes of vulnerabilities from products.  Our speaker gave the examples of using memory safe languages and vetting third party components before including them in your software.  We were reminded though that being "secure by design isn't free, it isn't cheap to implement".

Being secure by design is not enough for the modern world (if it ever was), so vendors should be providing products that are secure by default.  Configurations should be secure "out of the box" as this was considered a manufacturer responsibility.  MFA should also be enabled by default, and not an additional cost.  Customers should then have the option to weaken their system, but that needs to be their choice, rather than the default position.

You can read CISA's recent report on being Secure by design on their website.

SigStore to Secure the Code Supply Chain

This was a vendor presentation about how their tool SigStore helps to secure the supply chain by helping you manage the third party components you use in your application.  As this was entirely focussed on the product, there's not much for me to say here.

What You Need to Know About the EU Cyber Resilience Act

This talk was my first introduction to the EU Cyber Resilience Act, which I mistakenly thought was actually the Digital Operational Resilience Act (DORA).  To an extent they're related, but seem to cover different areas.

The Cyber Resilience Act aims to reduce cyber security risks to protect citizens, while also increasing consumer trust.  Despite being an EU regulation, currently going through its final reviews, it will apply to companies that do business, or provide services to the EU.  The act requires that suppliers:

  • Are secure by design
  • Have a vulnerability handling and incident reporting processes
  • Provide security updates to customers

Vendors will encounter a number of challenges when it comes to complying with the act, potentially due to become live (but not enforced) around May 2024.  Firstly, there's a possibly high cost of compliance and the need to understand complex regulations.  Open Source software is also in scope if used commercially, so companies that build their product off open source software, or provide a service exclusively using it, would find an obligation to help support Open Source development.

Products would need to be certified, and then recertified if there's a significant change.  All products with a "digital computing element" would be covered, both hardware and software, and the certification has to be conducted by a suitably accredited and non-biased provider.

The regulation pushes to get vulnerabilities remediated quicker, requiring vulnerabilities to the European cyber security agencies within 24 hours.  Software Bill of Materials (SBOMs) came up again, as a crucial tool to understand how components (and their vulnerabilities) would impact you.

Companies are going to need to keep an eye out on the regulation, and it would  not surprise me if there's a rush of organisations offering paid services to help companies get compliant.

Details on the act can be found here.

Overall conclusion

Developing software securely remains a challenge for companies, hobbyists, and charities.  Regulation varies across the globe, and things don't always align.  In order to remediate vulnerabilities quickly, you first need to know the vulnerability exists (so need a reporting policy / process) and then you need to know how the vulnerability came to be.  SBOMs are useful in identifying some issues, and should be something we all work towards having.

It's crucial that systems are secure by default, not just design, so basic security controls are present from the beginning.  If a customer wants to reduce their security, that's up to them.

As conferences go, I found this mini-conference useful in parts, but I think the panel sessions were not as useful as they could have been.  

Banner image: Banner imagery from the conference pages.