This working group is dedicated to editing the security section of the certification mark and as of June 16th on draft 0.1 reads as follows.
NB: The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are used as described in RFC 2119.
Background considerations for these recommendations:
This is designed in the spirit of Cyber Essentials and Cyber Essentials PLUS, and makes use of known standards such as OWASP top 10, SANS top 25, IoT Security foundation compliance guidelines, etc. It is also designed for assessment by ‘not-necessarily-security people’, and includes requirements for documentation and evidence where prohibitively expensive things are prescribed (such as penetration tests, security assessments, code reviews, etc.)
Threats to Consider
These are example of attacker ‘mindset’ questions (taken from a yet-unpublished source – MC) which are designed to capture how attacks happen, and encourage ‘threat response’ thinking.
- What else can you do besides (generic product description)? (you could argue this is a definition of ‘hacking’ in a generic way…)
– Are you really a microcontroller being used to flash a light?
– Do you have a firmware-controlled radio that could be easily repurposed?
– Do you have some advanced functionality that goes above and beyond what you need for the task at hand, and that I can use for other stuff?
- Can I turn you into a malicious device for blackmail?
– e.g. bugging, video recording, disclosing sensitive user data or personally Identifiable Info (PII) – that kind of thing
- Can I get data out of you that relates to your owner?
– e.g. PII again, usernames, passwords, secret keys for 2FA, private keys for encryption, etc.
- Can I add you to a botnet/BTC miner?
– easy ways to monetise pwned devices – get them to mine BTC to a wallet you control, or add them to a botnet and sell DDoS services a la Mirai clone botnets
- Can I think of any other malicious activity that would benefit me in some real way, that I can leverage to this device and others?
There are 5 main sections based on how to apply secure practices and write secure code to IoT:
- Backend Service Systems
- User-land (web/mobile app) considerations
- Device considerations
- Industrial/commercial considerations
- Business process considerations
NB – there is significant overlap in this section! But we are all thinking the right kind of things.
Backend Service Systems:
Requirement Description Resilience to well-known attacks OWASP Top 10 (2017) and SANS Top 25 should be considered as sound baselines for security. These should be considered in terms of inclusion in the SDLC. Cryptography – minimum cryptographic requirements for servers
- TLSv1.2 on all web-based endpoints
- Secure hashing
- E.g. Salted bcrypt/scrypt
- Secure PII storage
Defence In Depth – Additional secure setup options should be implemented
- Principle of Least Privilege
- Web Server users should not be running as root/admin
- API service users should have limited access
- Managed access to data
- Do DB users need to write to a DB they only search in?
- Do DB users have access to DB’s they shouldn’t do?
Reliable and appropriate patching procedures should be evidenced
- Patches should be regularly applied to any system that is internet facing as a priority, within a reasonable time frame from patch release
- Critical patches, where applicable, should be given priority
- Monitor and patch with updates for core backend libraries, not just OS/peripheral updates.
- Only necessary ports are exposed to the internet (e.g. no access to debug ports like SSH/Telnet/etc., hadoop ports not open, SMB ports not open, NoSQL/SQL server ports not open, etc. etc.)
- Relevant Cookie flags and security headers (web) present where applicable (see OWASP guidelines)
User-land back-end service requirements (web or mobile apps – hosted):
Requirement Description Compliance against relevant OWASP Top 10/SANS top 25
- No SQLi – adequate protections/query parameterisation/filtering present
- Good protection against XSS – adequate filtering present
- Strong session management
- Good authentication management
- Random CSRF tokens that are strongly enforced based on last-issued token
Strong password policies
- Alphanumeric, with special symbols, and of significant permitted length
- Should be validated server side
Enhanced security should be roadmapped
- Allowing 2FA to be included in authentication
- Support for tokenized 2FA e.g. google authenticator
Device Specific Requirements:
Requirement Description Compliance with the relevant IoTSF Security Compliance Framework Compliance Class https://iotsecurityfoundation.org/wp-content/uploads/2016/12/IoT-Security-Compliance-Framework.pdf
- IoTSF Security Compliance Framework as a baseline for device security, as OWASP top 10/SANS top 10 are for userland and backend systems.
- Relevant compliance class for the device to be determined by considering the threats described in the “Threats to Consider” sections at the start of this document
- Class 0 – little discernible impact, to class 4 – critical infrastructure or potential for personal injury
Good firmware management
- Ability to manage firmware for devices
- Where this cannot be automated, alerts should be generated for users to remind them how to do this
- Usage of latest available SDK’s
- Monitor and patch with updates for core backend libraries (e.g. wifi libraries, web servers, XML parsers, etc. etc.), not just SDK updates.
- Automated Patching Opt-Out should be included
- Users should be warned of the implications of this
- A known-good failsafe firmware should be available
Usage of suitable Cryptographic schemes
- Per Device Private Keys
- Use known-good cryptographic schemes such as:
- AES256-CBC with random IV’s
- RSA based with key strength of 2048 (ideally 4096) bits
- E.g. NaCl for public/private keys
- Use demonstrably cryptographically secure TRNG’s/PRNG’s
Admin User Management
- Ability and requirement to change Administrator/root access passwords
- Device-unique passwords should be loaded into each device at production
- Where this is not possible, the admin/root password is to be changed on device first setup or admin first login, whichever happens first
- Specific account that hidden backdoor accounts are not to be included on production releases
Fair use of HSM’s
- Use of on-chip cryptographic accelerators where available
- Use of secure storage options where available
- Usage of CRP where available
- Only necessary ports open/available
- All services that handle sensitive data have adequate authentication
- No debug ports are available (ssh/telnet/etc.)
- No unnecessary services (e.g. FTP, TFTP, SMB, etc.)
- Documented moves to detect and block basic brute force attacks (e.g. password bruteforcing, WPS Pixie Dust, service bruteforcing, etc.)
- Remove Debug/Development headers from PCB (JTAG/UART/etc.)
Data controls should be in place
- Factory reset should exist to a known good firmware image (as above)
- All user/account data should be removable by the user
Additional Industrial Requirements:
Requirement Description Hardware Security options
- Ability to lock devices to hardware security tokens e.g. yubikeys
- This can act in place of per-device passwords/private keys
Resilience to local/adjacent subnet attacks
- Strong physical security
- Ability to filter by source IP on device
Requirement Description Clear Contact Information Security Contacts should exist and be known throughout the business
- A SPOC (Single Point Of Contact) should be considered
- Where this cannot be done, and there are multiple contacts, it should be clear who does what
- Minimum required contacts to be listed for this section should include:
- Contact for privacy matters/queries
- Contact for security matters and vulnerability disclosures
Support for lifetime of device Ability to support the device for its intended lifetime and a reasonable time beyond this.
- There should be a lifetime stated to users
- End of Life T&C’s and End of Life actions should be well defined – including in case of bankruptcy, takeover, etc.
- Should include ‘what happens to my data?’ and ‘what happens to my device(s)?’
- Clear list of data sharing partners should be available
- Clear storage policy should exist for data
- ‘Forget Me’ functionality that deletes all user data and account information from company stores
- Plain English verified documentation
GDPR Readiness To be performed as needed by the law coming in May ‘18 Security Penetration Testing
A planned ‘first-pentest’ with a follow-up action plan for resolving the results of the pentest A working Disaster Recovery plan, Vulnerability Disclosure plan, and Breach Response Plan
- Breach Response should have relevant technical, business, and legal contacts within it
- You should know if/when you were hacked
- You should know what to do
- Disclosure Response should exist, and have relevant technical, business, and legal contacts, as well as a workflow for how to raise tickets, assess severity, etc.
- Disaster Recovery should be tested regularly e.g. to ensure backup restoration works
IDS/IPS planning A planned introduction of monitoring software with alerts generated for the right people Future Planning Documented continuing review processes that evidence security as a regular agenda point Secure Technical Config in Business Operations
- Restricted physical access to production systems
- Limited number of large-scope administration accounts (such as Domain/Enterprise admin accounts)
Secure Development Lifecycle
- User of Version Control
- Formal releases
- Comprehensive release notes
- Repeatable builds
- Test-Driven Development (or at least tests included with code)
- Basic Vulnerability Checks built into the CI/CD pipeline
Open Source Awareness
- Open Source usage list – all modules, libraries, service code, etc.
- Where applicable by open source license, all software should be published (e.g. GPL2)