Version 0.9 -- This Health-Check list is in DRAFT stage of development.
The purpose of the Cybersecurity Health-Check is to help organizations evaluate themselves and others they do business with against a set of common cybersecurity program best practices. The health-checks are divided into key cybersecurity oriented realms which support a full IoT solution; and will also apply to other non-IoT specific solution segments.
These Health-check lists are not meant to be all encompassing security controls programs, but to instead help gauge the health and overall due diligence of the organization's cybersecurity program. At the same time, they are also quite comprehensive in terms of key, industry best-practice security controls that will frame a robust cybersecurity program for any organization.
This Cybersecurity Health-Check list of security controls can be used as a direct gauge of where an organization falls in terms of the health and maturity of its cybersecurity program. They can also be used more generally as a controls list to be drawn upon for requirements or compliance purposes.
The "health-check" of evaluating a cybersecurity program is determined by reviewing each control relative to both a Usage Context, and a Degree of Usage Rating, as shown here below:
- In/for Enterprise Network
- In/for Production Network
Degree of Usage Ratings
- Not Used
- Partial--Ad Hoc/Informal
Product development - control points
An end-to-end data security review is done on the solution early in the development cycle.
An end-to-end data privacy review done on the solution early in the development cycle.
A technology attack surface review is done on the solution early in the development cycle.
Threat impact and business risk is determined early in the development cycle.
Attack surface protection/threat modeling is done early in the development cycle.
Practices outlined in the IoT-SI: Security Design Best Practices are adhered to.
Needed Security controls requirements are defined and reviewed for development cycles.
Needed functional security requirements are defined and reviewed prior to development.
The security architecture of the solution design is reviewed prior to development.
All implemented third-party code is inventoried and managed for security patching.
Static application security testing (SAST) tools are used on all custom and third party code.
Dynamic application security testing (DAST) tools are used on all relevant applications.
Manual code review is conducted on high-value/threat sections of the code base.
Fuzz testing is done on data format input processes of interfaces and protocols.
No final source code is released with known High and Medium severity vulnerabilities.
Testing of security-functionality is conducted during the Test phase.
A final data security and privacy review of the solution is conducted pre-release.
A vulnerability assessment of the complete system solution is conducted pre-release.
A periodic manual penetration test of the complete system solution is conducted.
Identified security defects from testing are catalogued and tracked to conclusion.
Regular, secure back-ups of code repositories are conducted.
Code repositories are governed by least-privilege-access with two-factor authentication.
Developers have training on secure coding and development practices and guidelines.
Separate environments exist for Development, Test, and release of Production code.
A Product Security Release Validation Lead is identified for each shipping product or service.
Online public mentions of Product/Service vulnerabilities discovered are monitored.
Product supply chain vendors are contractually bound to S-SDLC activity requirements.
Prior to deployment/release a Product Security and Privacy Signoff verifies compliance.
Bug bounty services are utilized for customer-facing services.
Risk management processes for product risk acceptance and tracking are in place.
Practices outlined in IoT-SI Cybersecurity Health-Check: Network & Cloud are adhered to.