Testing Coorporate CIS18 Security
Let's help make the implementations more resilient and functional. As always.
One way for companies and organisations to fulfil regulatory security requirements is to implement CIS18, aka the Center for Internet Security's 18 Critical Security Controls.
Testing professionals, though, rarely consider this high-level management concern. We are often stuck in the mechanics of delivering features, sprint after sprint. This is a shame, as one of the characteristics of a good testing professional is the ability to see the bigger picture and address customer pain points across all kinds of requirements.
A testing mindset is equally beneficial for implementing the CIS18 controls. The testing oracle here is the company's risk appetite. The risk appetite is a balance of the customer space, the chosen internal technologies, and market regulations—probably more.
Jesper Ottosen
While many things can be automated or tool-supported, there is still a human component to following the guidelines. As with all "pirate codes", it's more of a guideline, and thus fallible. Eventually, the controls will be challenged and hacked on purpose.
Let's help make the implementations more resilient and functional.
As always.
How to test for all of these controls and similar security requirements is part of my daily work. It's a bit of a privilege, I know it might not be the place for all testers to operate in. It might be mostly for senior and staff testing people. I want to share that it's a possibility and give you a way to exercise your testing skills.
There are 18 - let's dig into them, it's a long list.
1: Inventory and Control of Devices
This control is why internal IT wants to list all corporate devices and phones, even the device test lab and cloud virtual machines. To many testers and developers, this is more of a nuisance than an opportunity. Think of it as testing any inventory system. The testing opportunity here is to think about CRUD and edge cases. Can devices be added or disbanded without being registered? If you can help discover unaccounted devices, you help increase both the bottom line and the security posture. You can also help in designing a preferred path that makes it easy to request new environments that are listed from the start.
2: Inventory and Control of Software Assets
Similarly to #1, as a testing professional, you might experience this as a pain more than a place for testing activities. Within the context of software assets, we can help figure out what constitutes an "approved" software asset and how well this is enforced. In some companies, this might be loose guidance, while in other companies, this might be strictly monitored and enforced. How would you balance rules from seeking approval for any software on one hand and free installation of everything on the other hand?
Side note: if you are interested in games around language and rules, check out https://novehiclesinthepark.com/.
3: Data Protection
All companies have data somehow. Yet, not all data is equal. Some data is public information, some might be personally identifiable (PII) data. Or data that should not go into a random Signal chat. Let's make some tests based on the categories of data and the risks of exposing the data. One test I often use is what consequence it has to change something from a protected level to a public level. Another test could be to try to see if data on disbanded devices is erased. Perhaps your business domain requires extra protections around credit card info, drugs or similarly exploitable data.
4: Secure configuration for Devices and Software
This control is all about hardening devices, VMs and versioned software - both the initial configuration and the ongoing updates. Like always, run Windows updates on Patch Tuesdays and don't allow company phones that do not receive OS updates. The same goes for software: make sure to patch browsers, tools and coding frameworks. Have a plan for your test environments, or if you actively decide always to be one version behind, or need to have old browsers around.
There are many great tools to harden and patch devices, so no need to reinvent the wheel and roll your own. Help to make it easy for people to be up-to-date, but also keep an eye out for the business edge cases that still need Internet Explorer.
5: Account Management
For this control, the tester should be curious about how credentials and authorisations are handled across systems, admin accounts and user accounts. It can be beneficial to apply a hint of a hacker mindset to explore how account management is handled. Are there passwords in your code repositories? Are there passwords for your service accounts rotated or pinned in a public chat in Slack? When Jessica stops at the company, who controls your Postman licenses? Are your environments set up with default factory credentials?
6: Managing Access Control
Depending on your corporate access controls, the credentials and IT privileges can be created, assigned, updated and revoked. This could be ripe for some good old CRUD testing. Some companies invest in internal systems for this, while others roll their own. (Don't roll your own crypto - or security solutions). It's a great place to ask "What If" and explore edge cases of human behaviour.
7: Monitor threats and vulnerabilities
While hardening devices under #4 is prudent, unwanted things can still pop up on your network and in your platforms. There is already a great number of standard solutions. Browsers and OS's come with some basic protection against malicious sites, etc. A testing mindset is probably best spent in helping explore what things to monitor and how vulnerabilities could creep in.
One special area to be aware of is "supply chain attacks", where your favourite plugins and libraries are compromised. Or that your junior developer has asked an LLM for a library that doesn't exist for real, but still has infected.
About
8: Audit Logging
Ask for audit logs in the applications that you test, and see to it that they are captured somewhere easy to find and query. It not only helps the testability and observability but also the security. Plenty of open-source solutions exist, so spend your energy on setting good guidance on what to log and what not to. Be aware of logging personal and other confidential data.
9: Email and Browser Protections
This control is similar to #4 above, but is important since this is how phishing and malware creep in. If you have to test an email protection, set up a sandbox account first. Good test environment practices are often forgotten by security hacks, so help add a structure and awareness to testing "live".
10: Malware defences
We don't want viruses or info-stealers in systems. Be inquisitive about finding paths that the malware can enter and spread. Be on the lookout for old file shares, open ports, or similar upload endpoints. Shut down dead systems, which will improve security and save your company money.
11: Data Recovery
Have a disaster party! Seriously! If there isn't a plan on how to recover, create it. If there isn't a requirement for how much data your business can afford to lose, establish both the RTO and RPO tresholds. This threshold topic has been my gateway into the space because I volunteered when the task needed doing.
Jesper Ottosen
12: Network Infrastructure
This would usually be about your company network, that is, the wifi and LAN that you work on. But consider the network of the solution you work on, too. It might be a virtual cloud network, a data center network where your solution is hosted. Ask questions, investigate the network design, and help the network engineers to have your network protected and patched. No admin/admin on the office routers!
13: Network monitoring
So in #12, we manage the network, here it's about monitoring what's happening on the network and blocking unwanted events. There are plenty of standard solutions to implement both wrt allowlists/denylists and feeding network events to a data repository. Depending on your company culture for objective and auditable documentation, work with the network team to document that they have set it up as intended.
14: Security awareness
One place to start, without going overboard in training solutions and mandatory questionnaires, is to collaborate with the developers around secure coding and application development. Introduce the developers to the "Alice & Bob Learn" book series for practical tips and best practices for applications and frameworks.
If you are already a quality coach, looking into expanding into your advisory to the security and compliance domain.
Jesper Ottosen
15: Service Provider Management
All IT shops are based on someone else, especially considering all the Saas solutions for all kinds of employee-related services: payroll, enrollment, etc. Be the one who addresses when sensitive business data is being shared externally or when company processing is outside your company. All for a good reason, but you need to risks of data leaking. The same with your corporate Active Directory, help looking into business continuity plans and exit strategies for the IT you consume.
16: Application Software Security
Finally, a control that we recognise and many testers have looked into: Application security. A skill with a range of methodologies, tools and places to run with the "hacker" mindset. Which is fine to an extent. Remember to analyse also things you take into building or supporting your solution.
17: Incident Response Management
Organisations set this up to react to security events. Much like when bugs happen in a system under test, yet here it's in PROD, and it's a security issue due to a malicious attack. While it could be cool to test this, be careful and always have a pre-approved plan and scope before doing anything like this. In some places, even running port-scanning tools internally can be considered hacking. Instead, have what I call a "desk test", a "dry run", or "dress rehearsal" to learn that you can react to an attack.
18: Penetration testing
As with #16, this topic is more recognisable to the general tester. It's about having recurring pentests of both the solution you build and the corporate solutions you are on. As with #17, have an approval in place first. Do test both systems, processes and people. Consider, though, that penetration itself is a field that requires study and practice, so while you could do it, consider if you want to do it, or hire someone. It's ok, not to master all kinds of testing.
Thank you for sticking around 😄
