Many companies are currently trying to wrap their heads around the Log4j vulnerability and its impact on their operations and applications. While it’s critical to resolve the current problem, we also have to acknowledge that we’ll be reacting to more of these in the future. In a number of cases this is often down to the fact that organisations don’t appear to grasp the importance of the basics.
Our definition of “the basics” is fairly simple:
- Inadequate management of user and system credentials
- No multi factor authentication on external applications/websites/services
- Default configurations of hardware and software
- No encryption on mobile or storage devices
- Little to no user security awareness
- Excessive access rights to shares, databases and applications
- Vulnerability and patch management
- Weak network access controls (physical and logical)
- DevSecOps (only recently included but critical nevertheless)
The list isn’t exhaustive and we could easily add another 10 items but most of these tasks are things that, in one form or another we’ve been doing for nearly 20 years and should be second nature by now. Much like the human body’s autonomous system, these should be fully automated or part of a well defined onboarding process and only require monitoring in case anything goes wrong.
Security is about maintaining the confidentiality, integrity and availability of data and systems, something that we’ve known for years but it still requires manual effort to deliver. If we were to take some time to automate the basics within a clearly defined set of guardrails, we would eliminate a significant number of risks associated with them and give our overworked admins time to deliver on the projects they’ve also committed to.
- If the java logging library had undergone rigorous testing through a devsecops process would the vulnerable version have been released?
- If a certain fibre/internet/media provider had required that a default password be changed when the customer had received their modem would they have had to apologise for the mistake?
- Would local encryption of the multiple laptops and USB keys lost over the years have stopped the leakage (and subsequent fines) of the sensitive information on said devices?
- How many breaches would have been stopped if a well managed vulnerability and patching process existed beforehand?
Again, the above list is not complete but it shows that a large number of breaches or leaks may have been stopped simply by getting the basics right.
So how do we get the basics right? Most importantly, it’s going to require senior management buy-in to build a multidisciplinary team structure, and provide it with enough resources and support to plan, develop and implement the required manual and automated processes.
Secondly, you’re going to have to reallocate some of your most experienced technical team members to the programme team and give them a suitable budget. This semi-permanent team should comprise the most senior and capable, solution focused resources that you can spare, but take note that removing them from operational tasks will not be easy due to the knowledge and experience they have in their roles. Let this team define the end state, as career technologists this is what they do everyday and they’re good at it.
Keep in mind that this team is going to disrupt the operations of business and technical teams so the programme management team will have to resolve those issues. Communicate the need for this team early on and continue offering updates as the programme progresses.
Which leads us to the bad news, this is not a three week or a three month programme, depending on the resources assigned, getting the basics right is going to take at least a year of hard work and commitment. It’s also going to be difficult fixing problems in your organisation which have existed for years because “that’s how we’ve always done it”. Technical and procedural debt have to be ruthlessly removed and replaced with new processes and tooling which offers automated ways to manage access requests, code scanning, device provisioning/onboarding and software patching (et al).
This programme is going to require significant focus and effort from your best technical resources to get this done within a reasonable timeframe. They will have to call on subject matter specialists within the IT and security teams for assistance when necessary and must have the full support of senior management.
Now for the good news, your teams will buy into the programme. Technologists want to be able to implement new and exciting technologies instead of responding to an incident thanks to a vulnerability which shouldn’t have existed in the first place. Give them the space to fix the basics properly and they’ll do it, and your organisation will thank you and them in the long run.