We have come a long way in the cybersecurity sector in a relatively short period of time, but there remain many challenges in day-to-day operations that create security gaps in many organizations. One of the most common is tied to how we build our solutions, making sure they are secure out-of-the-box instead of only being evaluated during a pen test or annual review, and finding out then that there is much more that needs to be done to achieve data security.
Starting out with the blueprints
If we were to liken our IT security processes to traditional workplace health and safety operations, there are a lot of parallels that show what we’re already doing right, as well as highlighting what we have been missing and should consider adopting into our workflows.
For example, in the traditional health and safety world, there are standards that help to ensure that the environment is set up in a safe way from the very start. Recognizable precautions, such as the requirement to ensure that each floor of a building has fire extinguishers or controls to ensure there’s sufficient ventilation, stand out to any observer. These are things we often take for granted in the workplace, even if checking they are in place isn’t a part of our day-to-day activities. Instead, we depend on them being factored into the original design and being set up correctly before we start using the building.
These simple safety controls aren’t too far removed from many organisations’ use of cybersecurity standards, like those offered by the Center for Internet Security (CIS), to ensure machines are hardened against risky configuration states by default. Like the physical safety controls for buildings, the best time to put them in place is at the point of deployment, and, just like adding a new fire extinguisher to a building, it is always good to ensure you’re keeping up with good practices by protecting your infrastructure with basic controls.
Maintaining a secure by default state
Once we know our key safety requirements are in place, we can’t just stop there – fire extinguishers need to be regularly inspected and replaced when necessary. Similarly, ventilation ducts may need to be cleaned regularly and modified if changes to the internal layout of the building are made.
In the same way, your server hardening needs to be thoughtful about the future. As new applications are added over time and increase your surface area, so too do new safety controls become necessary for the new features of that application. Change processes should ensure that if the risk is added over time, so should controls that minimise or remove the risk associated with the changing nature of the server’s role.
Expanding should prompt reviews - not just time since the last review
If you’re not regularly checking that your servers are still as effective at protecting your information, you might as well have hidden the fire extinguisher away in a cupboard and forgotten about it. Without regular testing to ensure that your controls work, you shouldn’t just assume they’re keeping you safe when you need them the most.
Risk Assessments are a common function of health and safety teams in many companies, and whilst similar concepts are applied to project management in IT, they may not be treated in quite the same way in the world of cybersecurity. In both worlds, a risk assessment should be completed periodically and its findings must be taken seriously, but in the IT world, all too often, cybersecurity findings aren’t given enough weight against operational needs or are limited to just once a quarter or an annual set of tests. Just as you wouldn’t risk running your business with fire hazards flagged in your corporate headquarters, you shouldn’t be running your customer’s business on servers that score poorly for good general hygiene or haven’t been checked for months.
One of the key reasons this is a common issue is that responsibility for IT security is rarely shared with everyone and built into the day-to-day change processes that many businesses have. In health and safety, it’s not just key individuals reviewing and acting upon red flags, but individuals who each contribute in their own way – be that being a fire marshal or a person who ensures that wet floors aren’t a risk.
In the same way, security for IT needs to be everyone’s job – developers, third parties, and system administrators. Each has a chance to highlight risk, and each can help others by addressing a little bit of the hardening process – be it by running scripts to harden hosts, avoiding introducing new risks, or simply highlighting the need for a security review after making a change to a system. Once such an approach is in place, what can feel like a large burden can actually be more easily distributed, ultimately leading to success in the form of a safe and secure environment for all.