ASD ISM 1460 Secure by design vendor isolation mechanisms
What it says
When using a software-based isolation mechanism that consumes shared physical computing resources, the isolation mechanism is from a vendor that has demonstrated a commitment to Secure by Design and Secure by Default principles and practices, including secure programming practices and either memory-safe programming languages or less preferably memory-safe programming practices.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse software isolation tools from vendors committed to secure design principles and practices.
This control is about making sure the software you use to separate different parts of your computer or network comes from a trusted vendor. If the vendor doesn't follow safe design practices, you could be left vulnerable to security breaches, putting your data and operations at risk.
Free. Save your status, tasks and notes.
Why it matters
Using untrusted vendors for isolation mechanisms can lead to security breaches, exposing sensitive data and potentially bringing business operations to a halt.
How to implement
The IT team should assess current software vendors.
Ensure they follow security best practices by reviewing their design and development processes. This means checking if vendors use safe programming methods and languages to prevent security flaws.
Procurement should work closely with the IT team to choose vendors.
Focus on those who actively demonstrate 'Secure by Design' principles. Seek recommendations or case studies that show their commitment to security in their products.
Managers should ensure regular training sessions for staff.
Emphasise the importance of choosing and using software from reputable vendors, highlighting the potential risks of using poorly designed software.
IT teams should perform regular audits of vendor software.
Check for ongoing commitment to updates and security patching. This involves reviewing vendor communication and ensuring they provide timely updates for any security vulnerabilities.
Executives should allocate budget for security-oriented software vendors.
Highlight the necessity of investing in securely designed software as a way to prevent costly breaches and demonstrate to stakeholders a commitment to security.
Keep it running
Regularly review and update vendor agreements to ensure continued adherence to security standards as technology and threats evolve.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
vendor documentation showing their secure design process.
Look at
the details of their security practices and any certifications.
Good evidence
will include documentation of 'Secure by Design' principles and recent security audits.
- Check 2 of 5What an auditor asks for
Good evidence
is a list showing the use of safe languages and practices.
- Check 3 of 5What an auditor asks for
Ask for
a record of software updates and patches from vendors.
Look at
the frequency and nature of updates.
Good evidence
is regular updates, especially for any security issues.
- Check 4 of 5What an auditor asks for
Good evidence
includes regular, comprehensive training sessions specifically addressing secure software use.
- Check 5 of 5What an auditor asks for
Ask for
vendor selection criteria documents from the procurement team.
Look at
security considerations within these criteria.
Good evidence
will show a prioritisation of security and reputable vendor practices.
Mappings
Closest match in ISO/IEC 27001: A.8.27, Secure system architecture and engineering principles, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.27.
ISM-1460 requires that when an organisation uses software-based isolation to share a physical server, the isolation mechanism comes from a vendor demonstrably committed to Secure by Design/Secure by Default, including secure programming and (preferably) memory-safe languages or practices. Annex A 8.27 requires organisations to establish and apply secure system architecture and engineering principles across information system development activities, which would include the engineering principles used to select and trust an isolation mechanism. ISM-1460 is more specific (virtual server isolation vendor assurance and memory-safety expectations), while Annex A 8.27 is broader and applies to overall system engineering rather than supplier product selection alone.
This control partially overlaps A.8.28.
ISM-1460 requires the isolation mechanism vendor to demonstrate Secure by Design/Secure by Default practices, explicitly calling out secure programming and memory-safe languages or practices. Annex A 8.28 mandates that secure coding principles are applied to software development, which aligns with the secure programming expectations embedded in ISM-1460's vendor selection requirement. Annex A 8.28 is generally about how software is coded (typically within the organisation or its development arrangements), while ISM-1460 is specifically about procurement/selection assurance for virtual server isolation products.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.